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.
Summary: | Adding library causes huge I/O load | ||
---|---|---|---|
Product: | java | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Source | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dstrupl, issues |
Priority: | P2 | Keywords: | PERFORMANCE, PLAN |
Version: | 6.x | ||
Hardware: | Other | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 191316 | ||
Bug Blocks: | |||
Attachments: | Result of self-profile and export to ... action, hopefully openable in NetBeans profiler |
Description
Jaroslav Tulach
2010-05-26 14:12:30 UTC
My suggestion is to reimplement the deleteRecursively method. Instead of doing the delete, it shall just rename the folder to some temporary name. Then it shall do the delete in a background thread, possibly using the idleIO(Runnable) provided by the masterfs. As a result the UI will not be blocked, the system will delay the removal of old files until later and the user will sooner see the reindexed values. Created attachment 99499 [details]
Result of self-profile and export to ... action, hopefully openable in NetBeans profiler
The main problem is that deleteRecursively is called even when not needed. In your case it probably should not be called at all. I've changed the impl to not to call it when nothing changed. Delete only changed files when something has changed. deleteRecursively is called only when huge amount of crcs has changed (rare case). Anyway I will will an enhancement to benefit from slowIO when available as an API (http://netbeans.org/bugzilla/show_bug.cgi?id=191316). Fixed as described above in jet-main 4f78de51f641 Mentioned on http://wiki.netbeans.org/EditorPlan72 . Is there something to be done for 7.2 for this one? |