All these findings should be evaluated ...

Right everytime you switch to the IDE a record is being written into var/log/uigestures file and Preferences related to that are updated. 

I am tempted to close your report as invalid, or as designed. But I just decrease the priority and wait for you to explain why you believe storing preferences should be a problem.

Ok, so basically, tabbing into main view causes uihandler to change, and only thing that changes is some variable named MTTF.

Uihandler gets records appended like:
<record>
  <date>2011-05-30T23:34:30</date>
  <millis>1306787670633</millis>
  <sequence>820</sequence>
  <logger>org.netbeans.ui.focus</logger>
  <level>FINE</level>
  <thread>13</thread>
  <message>LOG_WINDOW_DEACTIVATED</message>
  <key>LOG_WINDOW_DEACTIVATED</key>
  <catalog>org.netbeans.core.ui.warmup.Bundle</catalog>
</record>

I tried to disable "provide anonymous usage statistics" but that did not matter.

Plus an odd thing is the \u0000\u0000.... part at the first line in uihandler.properties

Why this is a big deal is because when using default install, netbeans startup is usually extremely slow (on traditional HDD, mind). Plain startup without projects was something like 30 to 45 seconds or so before HDD requests stopped. And when opening a project and tabbing back and forth between browser and netbeans, every IDE activation keeps causing multiple HDD accesses. (Multiple plugins try to reread the configuration from disk or write something to disk). Opening a small sized php project (total of ~1000 files including the images, css, js, template files, PHP files etc) took 1.5-2 minutes.

At some point I got to a situation where after some time tabbing back to IDE caused 30-40 second hangs and memory/heap dumps in addition.

After I started netbeans as admin, removed mercurial, svn, local history, spellchacker plugins then all that extra HDD activity ceased. And there were only few HDD events remaining. I filed a bug about HDD monitoring (http://netbeans.org/bugzilla/show_bug.cgi?id=197927) and this bug about uihandler.properties.

So, in conclusion, is there a way to stop netbeans from logging all those events to the file constantly ? It would be a nice way to remove the last unwanted file accesses from IDE.

Note: right now, my netbeans starts up in 10 seconds when no projects are open and opening that PHP project takes additional 5-10 seconds. An order of magnitude difference when comparing to previous stats.

Disabling (or removing) these modules will prevent var/log/uigestures from being created:

$ find | grep uihand
./nb/update_tracking/org-netbeans-modules-uihandler.xml
./nb/update_tracking/org-netbeans-modules-uihandler-exceptionreporter.xml
./nb/update_tracking/org-netbeans-lib-uihandler.xml
./nb/modules/org-netbeans-modules-uihandler-exceptionreporter.jar
./nb/modules/org-netbeans-modules-uihandler.jar
./nb/modules/org-netbeans-lib-uihandler.jar
./nb/config/Modules/org-netbeans-modules-uihandler.xml
./nb/config/Modules/org-netbeans-modules-uihandler-exceptionreporter.xml
./nb/config/Modules/org-netbeans-lib-uihandler.xml

Don't forget to remove caches from var/cache/all*dat


Your observations about speed of processing of PHP project are interesting, CCing Petr Pišl, otherwise closing as won'tfix from ui gestures collector point of view.

IMHO it's connected with issue #197927, because it seams that in some cases the IDE listen on all file changes. So when is something change then NB tries to check what happened.

Jaroslav, do I understnd correctly from those filenames, that after removing those, I will be unable to report any exceptions from netbeans UI in the future ? Right now when an error occurs netbeans lets me te report it with few clicks.

And is the \u0000\u0000... first line in uihandler.properties really intentional ?

Petr, yes, it may be somewhat related, I did the original screenshot at the same time when I filed the other bug. After I was instructed to use additional settings in netbeans startup file, the file changes are no more monitored by netbeans and lot of the useless events went away.

But in general, the spellchecker plugin was also constantly scanning directories on each window focus. It searched multiple directories and files. I will have to try a fresh default install again with file monitoring turned off to see what activity remains from other plugins. But should I report a new report for each plugin separately or bundle things together.

In general this performance issue seems quite important, startup time 2 minutes is too big, and after disabling extra activities it went down to 10 + ~8 seconds, which is extremely fast in comparison. So the base IDE itself is fast to load things up, but just the plugins try to do too much. I bet you could reproduce similar startup issues on your own computers:
Take a PHP project that has html files, image files, css files, php files, altogether around 1000 files.
Make sure the project is in svn (local folders have .svn folders in them).
Open up the default full installation of IDE, measure how much time it takes.
Open up that project, measure how much time it takes.

Restart IDE, run as root/admin, disable all repo plugins, spellchecker, local history etc. So Java remains, PHP with database remains and few others.
In my machine, installed plugins list is: Database, IDE branding, IDE platform, Java, Java profiler, And, Junit, GUI builder, Java debugger, PHP, RCP Platform, Software as a service
Try to open up IDE again (complains about some missing stuff, confirm disabling the complaining plugin).
Try to open up the project.

Should have quite noticeable speed difference. In my opinion, seeing as spellchecker does directory scanning on each window focus and other plugins behave badly sometimes too, would it be possible for someone inhouse to do detailed investigation into plugins and check their performance and HDD activity. I'm sure that all that HDD accessing does not amount to much on a SSD, but on a regular laptop 5400rpm HDD, it makes quite a lag for startup and for focusing back to IDE.