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 166903

Summary:	Recent Files actions blocks awt >5s
Product:	utilities	Reporter:	Jaroslav Tulach <jtulach>
Component:	Open File	Assignee:	Andrey Yamkovoy <kaktus>
Status:	RESOLVED FIXED
Severity:	blocker	CC:	issues, jglick
Priority:	P2	Keywords:	PERFORMANCE
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Attachments:	Profiler snapshot

Description Jaroslav Tulach 2009-06-11 09:17:19 UTC

RecentFilesAction blocks AWT while creating its presenter. This seems quite unnecessary, only schedule the update to 
other thread and let AWT run.

This happens especially after code start, when file caches are empty and the time to execute RecentFiles.checkHistory 
is significantly increased by disk touches. Obviously, when disk "gets warmer", this problem will no longer be an 
issue (until the caches are flushed and replaced by something else, like hg update of another NetBeans repository).

Comment 1 Jaroslav Tulach 2009-06-11 09:20:13 UTC

Created attachment 83434 [details]
Profiler snapshot

Comment 2 Jesse Glick 2009-07-09 21:18:24 UTC

*** Issue 159659 has been marked as a duplicate of this issue. ***

Comment 3 Jesse Glick 2009-07-09 21:29:47 UTC

Also reported as

http://statistics.netbeans.org/analytics/detail.do?id=153546

though this just stays marked "in transfer".

In my case, posting the File > Open Recent File menu takes 5-10 seconds. Looking at
$userdir/config/Preferences/org/netbeans/modules/utilities/RecentFilesHistory.properties, I see 680 entries (!), mostly
file-protocol, but also some jar-protocol (e.g. src.zip entries), and some http-protocol (from Hudson workspaces) which
are slow to load. Many of these are rather old, certainly not "recent" files.

Looking at the code, it is clear there are several problems:

1. Whatever code is supposed to be removing old entries is clearly not working. First of all, RecentFileAction specifies
MAX_COUNT = 15 whereas RecentFiles specifies MAX_HISTORY_ITEMS = 20; I would think just RecentFiles would be responsible
for enforcing the bound. Secondly, RecentFiles.addFile can remove at most one old item at once, which is not very
robust. I would expect both load and addFile to remove _all_ the files after the cutoff.

2. RecentFileAction is loading the FileObject for each menu item. This is not really necessary. It can just take a
filename from the URL, and either

2a. Not display an icon.

2b. Add icons asynchronously.

2c. Remember icons when storing the file URLs, as we already do for the recent project list.

3. No code should load the FileObject for a nonlocal URL (i.e. not file-protocol) unless and until the menu item is
actually selected. This would apply to RecentFiles.checkHistory and RecentFileAction.fillSubMenu. (The client property
for the menu item should be the URL.)

Comment 4 Andrey Yamkovoy 2009-07-23 19:09:17 UTC

Thanks Jesse for the high detailed comments.
Looks like I fixed all the problems you reported.

Comment 5 Quality Engineering 2009-07-24 05:40:04 UTC

Integrated into 'main-golden', will be available in build *200907240201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c7e01c27c30d
User: Andrey Yamkovoy <kaktus@netbeans.org>
Log: Fix for #166903 - Recent Files actions blocks awt >5s