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 147403 - Regression of Create Mobility Project action on WinXP and WinVista
Summary: Regression of Create Mobility Project action on WinXP and WinVista
Status: RESOLVED FIXED
Alias: None
Product: javame
Classification: Unclassified
Component: CDC pack (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: _ tboudreau
URL: http://test-db.czech.sun.com:8080/Per...
Keywords: PERFORMANCE, REGRESSION, TEST
Depends on:
Blocks:
 
Reported: 2008-09-16 18:27 UTC by Alexander Kouznetsov
Modified: 2008-10-07 15:46 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Potential fix for testing (31.20 KB, patch)
2008-09-29 20:21 UTC, _ tboudreau
Details | Diff
Minor improvement to patch (31.05 KB, patch)
2008-09-29 20:35 UTC, _ tboudreau
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kouznetsov 2008-09-16 18:27:53 UTC
Performance test reports there is a regression in time of Create Mobility Project action on Windows XP and Vista:

WinXP 
1st run: 60% increase from 16 to 26 s, 
subsequent run: 108% increase from 6 to 13 s

WinVista
1st run: 42%, 17 to 24 s
subsequent run: 64%, 8 to 14 s

Threshold is 20 s for 1st run and 10 s for subseqent runs
Comment 1 Petr Suchomel 2008-09-17 08:37:37 UTC
maybe some additional time added by creating example midlet /from visual designer?/
Comment 2 _ tboudreau 2008-09-24 22:50:26 UTC
I did some profiling (suspect because it was done on a 1GB windows machine, so some "profiling" data may actually be the profiled VM's heap being swapped 
in and out of memory).  A few interesting tidbits:
 - After startup with no projects opened, pressing the Finish button in the new mobility project wizard results in ~10000 classes being loaded.  Has all the 
work on reducing startup classloading moved a lot more of the work here?
 - There seems to be some contention happening for the ProjectManager's mutex - the AWT thread spends 40% of its time in QueueCell.sleep(), which 
suggests that another thread has it locked.  This call is from the post-creation task's code that generates the sample midlet, which probably doesn't need to 
be run on the AWT thread.  An ugly fix might be to move that code to another thread, get the DataObject and use its OpenCookie to open it when it's done.
Comment 3 _ tboudreau 2008-09-29 20:21:59 UTC
Created attachment 70833 [details]
Potential fix for testing
Comment 4 _ tboudreau 2008-09-29 20:29:34 UTC
I've attached a patch that *may* fix the problem.    

It does two things:
 - Generation and opening of the sample midlet are done on a background thread *after* project opening
 - When the NewProjectIterator class is loaded for the first time, it will start a low-priority background thread which
does classloading in the background of a list of classes which will be needed when the user clicks Finish (if the thread
is still running, it is aborted so its work does not slow down project creation)

mrkam:  would you be able to run the performance tests with this patch to test if it has improved things?  I'm currently
working on a 1GB laptop, so any results I would get (if I knew how to run this test) would probably be meaningless.
Comment 5 _ tboudreau 2008-09-29 20:35:18 UTC
Created attachment 70835 [details]
Minor improvement to patch
Comment 6 _ tboudreau 2008-09-30 00:07:57 UTC
Hotfix committed.  Please verify.

104458	f9ecaa202ca7
104456	201c850c4925