There seems to be no significant performance problem rising in last builds.
I've tried to add a component to a very huge form (150+ components, 2000+ lines 
of generated code) and it doesn't take more than 2 seconds, CPU not even reach 
80% usage (on 733 MHz, 384 MB RAM, W2K, JDK 1.3.0).

Anyway, this could be same problem as in issue 11441 (code genaration and 
indentation is the bottleneck). What do you have set in Options -> Form 
Objects -> Use Indentation Engine?

I use the default settings but I'm also running off a 450Mhz machine with 
192MB ram and WinNT 4.0.

The result is very slow.

I took a look at IssueZilla for the forms. Aren't you planning to totally 
rewrite the form editor for 3.3 so it doesn't recreate the form-hierarchy 
everytime a component is modified? That would make a big difference :)

Not exactly - there is nothing done like "recreating the form-hierarchy", only 
all code is regenerated with each change - this takes most of the time. So no 
need to "totally rewrite the form editor", but just totally rewrite the code 
generation :).

That's pretty bad just as well :) So are you planning to change this 
anytime soon?

Also, I think it might help to 'buffer' 5-10 changes at a time before 
applying them to the source-code. That might result in a "quick-fix" 
solution for now.

A complete rewrite is not planned, however some kind of change-fire buffering 
is. But I still don't think this is such critical performance problem - adding 
a component or changing a property in a "standard" form takes quite minor time 
(on my machine :), growing up to 2s in an extreme one as mentioned.

To know more details: is that so slow generally - with any form (not the 
particular one) for you? Is the "update" time dependent on form size 
significantly? (You can find a very large form in issue 11441, attachment 1121 [details].)
And please try to change the setting Options -> Form Objects -> Use Indentation 
Engine (to see the difference).

Doesn't seem to be my form specifically. The forms got much slower after 
about 20 components were added. I think it's simply the number of 
components which is causes the problem.

I wish they'd let me install anything non-NT at work. It would solve 99% 
of my problems :)

UPDATE: Adding new components now takes anywhere from 5-10 seconds on the same 
machine.. I think this calls for some research. I'm going to attach the program 
in question so you can play with it in the form editor on your end. Hopefully 
you'll be able to reproduce a problem.

PS: I get the longest wait closing/opening the form editor (full 10 seconds) 
and sometimes randomily get cpu loads (100%) for 3 seconds or so while browsing 
the properties of my components (not changing them)

Created attachment 1604 [details]
*.form file

Created attachment 1605 [details]
Program in question

NOTE: The form editor seems to get slower and slower over time. Initially when 
I fire it up right after starting Netbeans it is quite responsive. Ten minutes 
into use it's extremely sluggish. I suspect a memory leak or something similar..

Memory leak - seems to be Property Sheet problem, see issue 12949.
In my opinion, your troubles are caused by new Property Sheet, could you try
build number less than 207 ( last build without new Property Sheet)?

I played with your frame:
build 212
- adding new component - 2-3 seconds 
- changing property - 2-3 seconds 
- opening frame 11-13 seconds

the same results as on build 205.

The opening frame time is too long, but it caused by number of components, I
think.

I think I found the source of the problem (which is why I uped the priority to 
P2). By clicking back and forth from one component in the form editor to 
another (not modifying anything, simply changing my focus from one component to 
another) I can get the memory usage of Netbeans to jump up from 50MB to 100MB. 
Hitting GARBAGE COLLECT using MemoryView does nothing (frees 1MB at most).

Therefore I am concluding there is a major memory leak in the form component. 
This one is pretty bad because 2 mins into use I must restart Netbeans to free 
all the memory. Otherwise the system becomes unusably slow.

Doesn't seem to occur in dev build 200..

Seems to be a duplicate of Issue #12949

*** This issue has been marked as a duplicate of 12949 ***

Resolved for 3.3.x or earlier, no new info since then -> closing.

Resolved for 3.3.x or earlier, no new info since then -> closing.