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 58333

Summary: Remove unnecessary resources from module JARs
Product: ide Reporter: _ rkubacki <rkubacki>
Component: CodeAssignee: issues@ide <issues>
Status: RESOLVED WONTFIX    
Severity: blocker CC: anebuzelsky, jglick, mkubec, pjiricka
Priority: P3 Keywords: PERFORMANCE, UMBRELLA
Version: 5.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 58335, 58337, 58338    
Bug Blocks:    

Description _ rkubacki 2005-04-26 13:57:26 UTC 
A pattern used for sample projects is to create a zip containing project and put
it into module JAR. Then the resources in this zip are extracted when user
instantiate the project. Total size if these samples is 527kB.

It will be better to keep these ZIPs separately and find them with
InstalledFileLocator when they are needed. That we way we can reduce the size of
module JARs that are mmapped to process. Also the less resources on classpath
the faster classloading.
Comment 1 Milan Kubec 2006-06-09 13:23:59 UTC 
Is there any prefered location for storing zipped sample projects?
Comment 2 Jesse Glick 2006-06-14 13:56:15 UTC 
I would rather try to find the root source of the inefficiency than move
resources around arbitrarily...maybe we need to do optimizations in the module
system. BTW does it help anything to move a resource into a Class-Path JAR?
Comment 3 _ rkubacki 2006-06-14 14:36:16 UTC 
If we keep these resources in module JAR files they are mmaped into memory (on
Linux and Solaris w/ JDK1.5) and thus increase VSIZE of process. Give their size
and how rarely we can think about their removing.

I know that virtual size of process is not that important as RSS but still can
save something when reading from these files as they will be smaller (and have
less entries). 

Moving them into another file that is on classpath does not help us here - we
only need more file descriptor and iterate more file in classloading.
Comment 4 Jesse Glick 2007-07-27 17:36:22 UTC 
Still recommend that we spend time instead on creating better module class loaders, not moving files out of their
logical place.
Comment 5 Marian Mirilovic 2011-05-24 15:48:56 UTC 
Nobody touched this issue in last 4 years - if you think it's still valid and anybody will work on the fix -> reopen