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 193720 - FileUtil.getMimeType can be slow
Summary: FileUtil.getMimeType can be slow
Status: RESOLVED DUPLICATE of bug 191777
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: PERFORMANCE
: 192256 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-22 03:47 UTC by esmithbss
Modified: 2011-05-24 06:49 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 175250

Attachments
nps snapshot (16.12 KB, application/nps)
2010-12-22 03:47 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 2010-12-22 03:47:29 UTC 
This bug was originally marked as duplicate of bug 182156, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE Dev (Build 201012150001)
VM: Java HotSpot(TM) Client VM, 17.1-b03, Java(TM) SE Runtime Environment, 1.6.0_22-b04
OS: Windows XP

User Comments:
esmithbss: Swapping IDE Color/Font Schemes from NetBeans 5.5 to NetBeans



Maximum slowness yet reported was 8015 ms, average is 8015
Comment 1 esmithbss 2010-12-22 03:47:33 UTC 
Created attachment 104382 [details]
nps snapshot
Comment 2 Vladimir Voskresensky 2010-12-22 14:46:04 UTC 
Jarda,
as an idea we can catch exception inside
org.openide.filesystems.MIMESupport$CachedFileObject.getInputStream
and initialize internal variable fixIt with broken stream marker (which is left null due to thrown exception forever), instead of reread each time by spending time and throwing same exception
Comment 3 Jaroslav Tulach 2011-02-07 12:20:31 UTC 
*** Bug 192256 has been marked as a duplicate of this bug. ***
Comment 4 Jaroslav Tulach 2011-03-03 16:50:16 UTC 
Originally named "11 invocations of FileUtil.getMimeType takes 11s", but that happens outside of AWT thread. The AWT thread is blocked in editor org.netbeans.modules.editor.settings.storage.EditorSettingsImpl.notifyTokenFontColorChange(). It fires an event (which could be done outside of AWT, I guess) and in response of that org.netbeans.editor.EditorUI.updateComponentProperties() blocks for a long time. Probably the slow code in org.netbeans.editor.EditorUI.updateComponentProperties() could be done outside of AWT and only alter applied in AWT...
Comment 5 David Strupl 2011-05-05 12:49:28 UTC 
Looking at the very last snapshot it seems that FileUtil.getMimeType invoked just once can be very slow under some circumstances. It doesn't matter whether it is invoked from editor or e.g. nodes as in 
http://statistics.netbeans.org/exceptions/exception.do?id=441573

Passing back to the core team for evaluation.
Comment 6 Jaroslav Tulach 2011-05-24 06:49:40 UTC 
In general yes, we need more effective mime recognizers.

*** This bug has been marked as a duplicate of bug 191777 ***