This feature seems to be not scaling to big program. I need to turn it off if possible.
Not that I’m aware of. But you can at least turn off the processing of the preprocessed source by toggling the “&” button.
That increases the speed for large programs – most of the time.
But, doesn't have to create the outline before it can filter it ... i.e., no performance gain except the UI? Or, is the constantly updated UI the performance problem? It does seem a bit jittery ... beyond need.
This is what I noticed too. It looks like it is still building the outline tree just not displaying all of them.
Is part of your source on the network? That is a known performance killer.
<brain dump>
The outline reflects the state of the AST. The AST is always built as you type. AST rebuilds are triggered after a short delay in typing (I think its .5 seconds). Starting typing again will cancel any current AST build and restart it. It ALWAYS runs in the background (not the UI thread). You can't turn it off otherwise you lose not just outline, but all code completion, toolbar and menu updates, color coding, find references, open declaration, code collapse sections, quick navigation aids, wizard behavior and a few other things.
The AST uses lots of CPU, some memory, a little r-code (generally not much, but sometimes class information is needed for super classes and interface stuff (only goes to disk if its not already cached) (cache size is roughly last couple hundred encountered classes) and whatever include files if you are referencing in the .p/.w.
The fewer include files and the smaller the program the better (obviously). Past tests have shown that somewhere around 8000 lines (total including expanded .i files) (depends on CPU and memory speed) (YMMV) (tests were done a few years ago, so newer CPU/memory combinations will stretch this higher) seems to be a reasonable upper limit of what most CPU's can handle without really noticing it in the editor. Larger than that and the AST gets slow relatively fast (garbage collection, raw processing time, tree depths...and so on). Mapped drives are killer for include files.
The AST reads include files when it encounters them, there is a bit of caching if the .i is open in some other editor or it was encountered previously while building the current AST. But really not all that much.
The AST uses the PROPATH of the project to resolve include files (pure java file search; it doesn't go through the AVM). This means if you have a long PROPATH and if the include file isn't right up there at the top, then you have an OS file location request for every directory entry before the include file is discovered. Mapped drivers are killer since file exists checks take orders of magnitude longer over a network drive.
For programs with lots and lots of structural elements (methods/variables/procedures...) closing the outline will save painting the outline which runs in the UI thread. This really won't save you a huge amount, but it can help a bit. The outline is repainted after every successful AST rebuild (i.e. not cancelled, no unrecoverable errors). The outline also tracks editor position, but it tries to be nice and only does repositioning when the UI is idle.
Preprocessor is also killer for large programs or programs that have lots of preprocessors that have to be resolved. Preprocessor is done through a .dll so it goes through JNI which isn't perfectly fast ( although its reasonable). Turning this off can help things.
Outline filters are useful for hiding stuff and making the outline shorter. They'll help with UI painting performance, but they don't affect AST building at all. They're applied directly in the view and run in the UI thread. They're quite lightweight to apply except for the regex name match which can be (relatively) expensive (compared to other filters).
One other item that can impact performance a bit is the class cache. The AST generally doesn't rely on class information but lots of other stuff does. So if you're using classes, make sure you are compiling/saving r-code where it can be found. Not having this slows all sorts of stuff down since the AST for those other classes has to be built to resolve dependencies.
Use an SCM solution and keep everything local (I know its not always practical/possible), but really, its the best solution. Use a tool like TeamCity or Hudson/Jenkins/something to do server side builds.
</brain dump>
So ideally you want all icode on a local drive and stick it as high up the propath as you can? And then avoid preprocessing?
“So ideally you want all icode on a local drive and stick it as high up the propath as you can? And then avoid preprocessing?”