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 - [68cat] [project] Inital project scanning takes excessive time
Summary: [68cat] [project] Inital project scanning takes excessive time
Status: RESOLVED INCOMPLETE
Alias: None
Product: ruby
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Erno Mononen
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2009-10-15 05:55 UTC by esmithbss
Modified: 2009-10-17 06:27 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
IDE Log File (68.40 KB, text/plain)
2009-10-15 05:59 UTC, esmithbss 		Details
Network Profiler for Load Sequence (523.16 KB, application/octet-stream)
2009-10-15 21:34 UTC, esmithbss 		Details
Second trace of startup scan time (542.95 KB, application/octet-stream)
2009-10-17 06:24 UTC, esmithbss 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.