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.
Build: NetBeans IDE 7.2.1 (Build 201210100934) VM: Java HotSpot(TM) 64-Bit Server VM, 23.6-b04, Java(TM) SE Runtime Environment, 1.7.0_11-b21 OS: Mac OS X User Comments: GUEST: Running make clean outside of NetBeans GUEST: I was doing a Git clone from a remote repository. This repository has about 5,000 files in it. St.Ev: svn up Maximum slowness yet reported was 24773 ms, average is 8985
Created attachment 130941 [details] nps snapshot
I am not sure whether it belongs to editor/parsing: significant amount of time is spent in URLMappers. Please check and/or advise if something can be done from the Parsing API side.
Looking at the source in ErrorAnnotator once more ... the time-consuming call is 'just' FileObject.getURL(), which is supposed to be very fast. I am inclined to believe the sampler data is not correct in that case, since it recorded ~260 creations of java.net.URI taking > 11 secs, which seems as a nonsense (no I/O happens in URI constructor I think). Would it be possible to iterate through the urls supplied to updateInError, map them to FOs, then lock the collect to only update entries for the existing FOs - lahvaci ?
(In reply to comment #3) > Would it be possible to iterate through the urls supplied to updateInError, map > them to FOs, then lock the collect to only update entries for the existing FOs > - lahvaci ? I would prefer to avoid that - there may be thousands of URLs passed to updateInError, and mapping all of them to FileObjects might take a lot of time (when this method was written, this would mean the FOs would need to be created as well, as the Java infrastructure did not use FileObjects for scanning. Now when parsing.api is using FOs, it would only be the conversion time.) I think it should be possible to split the lock, though, first copying the knownFiles2Error.keySet() into a local storage and then locking the lock just to update the INVALID status.
OK, I don't know the code details so I didn't want to suggest change in the sync model between updateInError and WORKER runnable; so far updateInError processes all the knownFiles without intervention. With a local copy of knownFiles2Error, the WORKER might add an entry with a matching URL to the shared copy while updateInError would be still processsing the local copy without that entry.
It seems that the slow initialization of URI objects cannot be fixed in filesystems. Can I reassign the issue back to editor/Parsing and Indexing, or somewhere else? Thank you.
(In reply to Svata Dedic from comment #3) > I am inclined to believe the sampler data is not correct in that case, since > it recorded ~260 creations of java.net.URI taking > 11 secs, which seems as > a nonsense (no I/O happens in URI constructor I think). The URI initialization time is really very strange, no I/O should happen there. I don't know how to fix this in filesystems. FileObject.getURL should be probably called off the ErrorAnnotator lock. There are only a few duplicates, and the bug is quite rare, decreasing priority.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss