This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 174603

Summary:	[68cat] [project] Inital project scanning takes excessive time
Product:	ruby	Reporter:	esmithbss <esmithbss>
Component:	Code	Assignee:	Erno Mononen <emononen>
Status:	RESOLVED INCOMPLETE
Severity:	blocker	Keywords:	PERFORMANCE
Priority:	P3
Version:	6.x
Hardware:	PC
OS:	Linux
Issue Type:	DEFECT	Exception Reporter:
Attachments:	IDE Log File Network Profiler for Load Sequence Second trace of startup scan time

Description esmithbss 2009-10-15 05:55:42 UTC

[ BUILD # : 200910140201 ]
[ JDK VERSION : 1.6.* ]

During the initial startup of the 200910140201 version (with a
pre-loaded gem list filled in from the command line before initial
launch) the first scan of all gems/platforms takes excessive time.

The IDE log lists everything and indicates the time necessary to load
the item into a cache.

In the attached log, you will find the time necessary to do this was
over 1565082 milliseconds or 26 minutes to scan 2 ruby projects, the
built-in JRuby system and 44 gems.

Comment 1 esmithbss 2009-10-15 05:59:33 UTC

Created attachment 89496 [details]
IDE Log File

Comment 2 Erno Mononen 2009-10-15 09:35:56 UTC

Yikes, that's pretty slow. I tested this and on my setup (Core Duo 2) scanning the same gems is around 20x faster; 
unfortunately I don't have a netbook for testing this. Can you please take a snapshot for this so that we could see 
where the bottlenecks are when running on a netbook? It would be enough to take it just for one platform.

Comment 3 esmithbss 2009-10-15 21:34:22 UTC

Created attachment 89575 [details]
Network Profiler for Load Sequence

Comment 4 esmithbss 2009-10-17 06:24:31 UTC

Created attachment 89649 [details]
Second trace of startup scan time

Comment 5 esmithbss 2009-10-17 06:27:50 UTC

I've added a second debug set for the startup scan time.

I looked through it and based on what I'm seeing, out of 1.52 million milliseconds of processing, 1.48 million
milliseconds appear to be spent on indexing within the RepositoryUpdater$Work.ind...() routine.