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.
Created attachment 154667 [details] NetBeans snapshot While NetBeans was doing its background checks, CPU usage was unusually high. Product Version: NetBeans IDE Dev (Build 201507150001) Java: 1.8.0_51; Java HotSpot(TM) 64-Bit Server VM 25.51-b03 Runtime: Java(TM) SE Runtime Environment 1.8.0_51-b16 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
Most of the time is spent in BrowserSupport.getBrowserURL() in FileUtil-Refresh-All thread. Reassign to web/html project. Please evaluate.
I can see that most of time is spent in: org.openide.filesystems.FileUtil.normalizeFile() 34.030685 51 308 ms (34%) 51 308 ms Reassigning, please evaluate. Thanks.
Method FolderObj.getFileObject(String relativePath) calls FileUtil.normalizeFile() only if relativePath contains "./", "..", or "/." Maybe we could investigate what relativePath values are passed from o.n.m.web.common.api.WebUtils.resolveToReference and, if possible, modify them to avoid the problematic substring. (I'd prefer not to modify FolderObj's getFileObject implementation, which could be quite risky.)
(In reply to Jaroslav Havlin from comment #3) > Maybe we could investigate what relativePath values are passed from > o.n.m.web.common.api.WebUtils.resolveToReference and, if possible, modify > them to avoid the problematic substring. No idea but will try to look at it. Thanks for the hint.
> Maybe we could investigate what relativePath values are passed from > o.n.m.web.common.api.WebUtils.resolveToReference and, if possible, > modify them to avoid the problematic substring. The paths passed to WebUtils.resolveToReference are usually relative paths contained in HTML source files, e.g. in src="path" or href="path", which is correct and should not be fixed. The slowness occurred probably due to some external change. Background scanning was in progress and, at the same time, HTML5 project started checking whether the browser should be refreshed. It checks (if I understand correctly) if the changed file is a dependency of the file displayed in the browser. This is the place where normalization of paths takes place. The only place that can possibly be improved is o.n.m.web.clientproject.DependentFileQueryImpl, which retrieves (and also normalizes) all dependencies, although only one dependency is checked. This may be a problem when the file references many resources (e.g. .css and .js files). It would be better to retrieve and normalize only the queried dependency. But (!) after the connection to browser is established, implementation of DependentFileQuery from module Webkit Tooling (o.n.m.web.webkit.tooling.networkmonitor.DependentFileQueryImpl) is usually used, which does not need to normalize the files. So the slow implementation is used only temporarily. My conclusion is that the main culprit is slow filesystem (it can happen sometimes, especially on NTFS). Improving o.n.m.web.clientproject.DependentFileQueryImpl may help, but the slow filesystem will probably block other important parts of the OS anyway. Reassigning back to web/HTML Project. Tomas, please decide whether the suggested fix is appropriate. > While NetBeans was doing its background checks, CPU usage was unusually high. Terje7601, can you still reproduce the bug with newer development builds?
(In reply to Jaroslav Havlin from comment #5) > Terje7601, can you still reproduce the bug with newer development builds? I haven't had this issue since I reported it, but that may simply be because it's hard to reproduce. Either way, thanks for investigating this.
I will have a look at DependentFileQueryImpl, thanks Jardo.
I tried to investigate DependentFileQueryImpl but it seems to me that getAllDependencies() method cannot be avoided (sorry if I am wrong, I do not know anything about the HTML editor). @jhavlin: Jardo, if you are interested in this issue, feel free to have a look at it, of course. So, closing as WONTFIX. Thanks for reporting.