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.
The problems is that while saving a .php file, it can sometimes take up to 10 minutes so save. I can still edit files while it's saving. When I use task manager netbeans is using about 1.7 Mbps. Seems overkill to save a 3kb file. The strange thing is I received a brandnew work pc and the bug is still the same. So I had the same problem on a old pc with Windows Vista and my new PC with Windows 8 64 bit, 8 gig, i5 core. Many thanks,
We need more info. Profiling snapshot, probably thread dump, we need to know if it happens with other files too (e.g. with some JS files, Java files, ...). But working remotely will never be fast. Thanks.
Created attachment 145351 [details] Profiling snapshot Profiling snapshot in attachment
I just see smarty doing something...TplEditorSupport.saveDocument(). Probably Martin can say more? There aren't any other php classes in the snapshot, just from smarty module. Sometimes there is also css support, so maybe it's somehow related.
I can be wrong but my investigation is following... Smarty doesn't run anything Smarty specific. But user has set reformat and remove trailing spaces before the save action. It obviously tries to get parserResult also from CSS support where is running likely some previous code completion task which wasn't cancelled yet (btw. it looks that the CSL API is not powerful enough for that yet). It means that ideally the CSS completion shouldn't run any more. But to be honest I'm afraid that the change in duration will not be any since the CSS parsing task is still necessary for the reformat action. The only chance I see is improvement of speed of the CssIndexer but hard to guess whether this is possible over network. :/ But I'm passing to css.editor for further evaluation of that. Reporter if you would like to workaround the issue in the meantime you should disable in options -> Editor -> On Save -> reformat action. That should help I suppose.
Thank you, I will try this.
Seems to be working fine. Thank you. Maybe there's another solution available? Works for now but reformatting is very usefull to conform with the code convention.
(In reply to Barreuh from comment #6) > Seems to be working fine. Thank you. Maybe there's another solution > available? Works for now but reformatting is very usefull to conform with > the code convention. Good to know that the workaround works to you. Actually I don't have another solution. You can wait whether the speed of the CssIndexer can be boosted but to be honest the work with remote files is always pain. Probably indenter could be faster, maybe it doesn't need parsed sources so you could create enhancement against editor support to switch between formating/indenting on save but it can bring issues in your formatting since indenter is not so powerful as formatter. Generally I'm afraid that usage of this feature is not good idea over network, sorry. But you can still wait for resolution from somebody who understand the css editor support.
I do not see any room for reasonable improvements in the CssIndexer's performance. You may try to ask someone who works on the indexing itself how in general handle such situations.
Sorry reporter but it looks like there is nothing to do about it. Files parsing over network will be probably always performance killer. If you would like to use remote files we can only advice to disable the reformat action on file save. Closing as wontfix.