Community
Participate
Working Groups
Build 20011105. On my home Win98 machine (256M RAM, plenty of disk), I did the following: - File / Import / File system - select c:\ - Select All - Select Types / *.txt It went away for quite a while, then crashed silently. No dialog, no .log output, nothing.
Looks like the problem is happening in ResourceTreeAndListGroup >> updateSelections(Map).
Well I think this is a memory and/or performance problem. I've run the test case multiple times. I've seen it truly crash (at various places in updateSelections) when running it in debug mode and at one point I did get an out of memory exception. Other times when I've run it, it just takes a really long time to complete (seems like it's dead but in fact it is churning away - 100% CPU usage). Some things I've noticed... When running the test case a pretty large amount of memory gets eaten up (around 80000K). The code creates an object for each file and folder on the disk and then filters through that list. It may make more sense to have ResourceTreeAndListGroup do the filtering based on extensions (so that it doesn't have to create the huge list to return to the ImportWizard class). One problem with this approach is that the class is too generic to handle this (assumes its input is an object vs. a file system element though from what I can tell file system elements are the only input used for the class). I also noticed some areas where it appears that redundant processing is occurring. For example, I believe primeHierarchyForSelection could include the following test at the beginning of the method: if (selectedNodes.contains(item)) return; And I think updateSelections could probably be made more efficient. Need to talk to TC about this (or whoever is most familiar with this code).
Tried a few localized changes to reduce the amount of memory being used during this operation. Looked at storing the path (as a String) with each FileSystemElement instead of storing the File object. Considered some kind of iterator approach by looking at how much memory would be saved by not returning the list of the selected elements. And looked at not storing the elementName (i.e., getting it from the fileSystemObject instead). None of these options made a significant difference in the amount of memory being allocated. One thing I did find that makes a significant difference (about a 20% memory reduction) is initializing the "files" and "folders" fields in the FileSystemElement class to null (vs. new AdaptableList() which creates a list with 10 empty entries). FileSystemElements of type "file" will never have any folders or files and FileSystemElements of type "folder" will often have folders or files (but not both), so not allocating all of these AdaptableLists makes a difference. Suggest changing FileSystemElement to initialize its files and folders fields to null and to set these to AdaptableLists only when a child is added. And suggest changing AdaptableList to have a new constructor that takes a size in order to support creation of an empty AdaptableList (or a specific size AdaptableList). The above will help the issue some - and if the OutofMemory bug (i.e., Eclipse silently crashes)is fixed and if the progress monitor is changed to indicate what files are being filtered during the FilterTypes operation, I think the problem will be sufficiently addressed. Any other solution will require redesigning the import dialog and its model.
Sounds like a good compromise. Please go ahead and make the changes you suggest.
Created attachment 242 [details] patch file in zip format
Created patch as zip file. Asking TC to review. Todd, I also included a minor change to the primeHierarchyForSelection method in ResourceTreeAndGroup. I think this method was doing too much processing, but please double check the change.
Changes checked and released. Added some additional text to the javadoc for the changes methods.
