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: | Mercurial Status agonizingly slow | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | ivan <ivan> |
Component: | Mercurial | Assignee: | issues@versioncontrol <issues> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | ||
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
thread dump while mercurial->status is very busy
another thread dump |
Description
ivan
2009-07-02 03:09:59 UTC
Created attachment 84277 [details]
thread dump while mercurial->status is very busy
Looking in the log file shows me a bunch of OOM's. log file attached. I suppose the OOM's mess up the state and send DiskMapTurboProvider into unknown territory? Decided the OOm's are irrelevant. I started a fresh NB and did another Mercurial->Status from the favorites view and it's already busy busy busy but no OOM's yet in the log. Instead attaching a thread dump from the early part of the busyness Created attachment 84278 [details]
another thread dump
1) All thread dumps look alike? It always hangs in the DiskMapTurboProvider? 2) Could you please pack and send me the mercurial cache folder? - ~/.netbeans/6.5/var/cache/mercurialcache. Mercurial has sometimes problems with a huge cache and it's access on the disk takes a long time (some people use to have .hg in their home folder which results in it's complete scan). 3) The second dump shows DiskMapTurboProvider.getAllModifiedValues operating in the AWT, which has been recently eliminated. Could you please try the latest dev build? - http://bits.netbeans.org/download/trunk/nightly/latest/ 4) 6.7 (or dev builds) has also a nice tool, which could help us a lot in analyzing the problem. Could you check it and attach a profiler snapshot? http://wiki.netbeans.org/FaqProfileMeNow I'll send 4 snapshots and the cache in a separate email. I took a few more snapshots and this is what I observed. It is the "Mercurial - /export/home/gdbgui/toolshg" thread that's constantly running and grabbing a lock. If I front the IDE causing repaints then the MercurialView thread starts waiting on it ... but these don't seem very long lasting blockages ... the locks goes away in subsequent snapshot. Can you elaborate on what you said: "people used to have .hg in their home folder which results in complete scan"? You mean a repository in their home folder? You mean Hg will scan siblings of the repository? In the various snapshots the AWT eventq is doing all kinds of different things not always related to DiskMapTurboProvider. I'm using 6.5.1 and will attempt to swith to 6.7 and see what happens there and try and use the profile me nwo button. > people used to have .hg in their home folder which
results in complete scan
We came across a few situations when some users had a .hg in their ~/ folder (don't know the reason however). Then the
mercurial plugin scanned all the files in the ~/... Most of the files under ~/ were unknown to hg (meaning they had a '?
status' in 'hg status'), because the of course had never been committed, but our plugin recognized them as 'Locally New'
and kept information about them in its cache. So eventually the cache grew into MBs of its size and every access was
painfully slow.
The cache should usually be max tens of KBs.
DiskMapTurboProvider (and the persistent cache) is no longer used by mercurial in 6.8. Status calls should be much faster now and AWT should not be blocked by mercurial. I was working couple of days with the netbeans sources hg repository (in 6.8) and never run into described troubles. Executing Mercurial>Status took maximally 10s (in most cases even less). I am marking this issue as VERIFIED now. Of course it would be great to hear from the reporter (ivan) - are you experiencing better performance in 6.8 in this case? Or does the problem persist? Thanks in advance (I mean in upcoming 6.8 beta / dev builds) My mercurial cache has been "under control" since I filed this IZ and then cleaned it up. I've been using 6.7 and haven't had problems with slow status. The giant cache that was causing me trouble looks like a one-time pathology and I'm not sure I can reproduce it to verify performance. I'll consider using 6.8B when it comes out. |