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.
in NB3.6dev since JavaCVS & VCS-CVS get merge including UI. ================================================ This bug has 2 parts: 1) using JTable It is significant performance problem that VCS Output has been change from JTextArrea (or what it was using before) to use nicer but very slow JTable. This became obvious when your cvs command run's c. over 500 files, and if output reach 1000 files the IDE became absolutly unusable:-( 2) command's output is not cutted down This is REGRESION: In previous release 3.5, the VCS Output was modified to prevent the OOME which could be easyly arrive when vcs command had large output. Thus in fact, the VCS output holds only actual c. 1000 rows of outputs, the old ones get forgotten. If you could do at least with point #2# it could help IDE performance very significantly
I'm confident it has to be fix into NB3.6 release
Dane, please, use the keyword PERFORMANCE instead of putting this word in the summary. Thanks.
The same approach was used in javacvs. So where is regression? GUI visualizers are the same. You mentioned OOME in point 2 - please attach exception stack trace(if it is easy I'm sure you can provide one). Where did you get information that rows are not cut? Did you count them :)? BTW I'll look at what is possible to do better.
well, I always considered the jtable display implementation as temporary in javacvs ;) anyway if I recall correctly, I managed to cut down memory consumption somehow by manipulation of the parsed output. (all states, file names etc.) used intern() -ed strings, that was especially important in the output of the log commands which produces a lot of output. I think the number of lines output was already cut in the old javacvs code. the slow thing is the keeping of focus at the end of the table..
2 Tonda> next time, you're qicker then me, I had some appointments to do, and has interupt work in the bug. Thanks you added the kw, instead of me:-) 2 Richard> you like stacktrace of OOME? How? It just print only OOME, so what do you whant to see? I don't understand you :-( Reproduction scenario is described in issue #36643 Well, I speak about regresion because the different approach was used in vcsgeneric module. 2 Martin>(maybe I've mistakely put this bug to wrong module..shouldn't be vcsgeneric?)
Yes, this is in vcsgeneric module. Also it affects only CVS integration.
One idea is to show table after command finishes and to show just status of command while it is running.
I could live with that provided that during command execution I see clearly that it is running plus some statistics and complete detail is available later.
I tried this on my laptop (Martin and Tomas are witnesses) with memory monitor and we can't see any performance or memory problem. I checkouted standard and ide modules. CPU is low (cca 2%) memory is growing very slowly - about 40MB. Guys from performance , could you help us to investigate, please? thanks!
Lowering rpiority to P3 - it is unreproducible on Dan's computer as well. I leave this open in case we are able to reproduce this.
Yes, that's true :-o I can't explaint it :-( Always, then I'm working alone, my CPU is very busy,MEmory comsumption is high, and when I'm showing it to someone else, everything's running smooth without any problem :-((( The only thing where could be problem is that it used to happen me on jdk1.4.2_xx but since the jdk1.5 was released I switched to this new one...
I've reproduce it again. Once or twice on current DEV builds and Once on NB36 #200403101830 The possible reason might be: ============================== - I have more then one week un-updated sources ! In all cases I've performed CVS->Update on the root of CVS FS (via vcs Tolbar). Mounted CVS FS contains sources of nb_all. I don't remember if I also used build-in client, but definitely as a pserver once I used bouth: cvs.netbeans.org and allias cvstunnel here is list of checkouted modules: ----------------------------------- accelerators ant antlr apisupport apisupportx applet archivesupport autoupdate a11y beans beriltest classclosure classfile clazz collabnet contrib corba core cpp cpplite crosscompile CVS CVSROOT das db debugger debuggercore debuggerjpda debuggertools diff editor edu emacs experimental extbrowser externaleditor filecopy form formeditor freestylebrowser html httpserver icebrowser ide image innertesters installer itutor i18n jarpackager jasm java javacvs javadoc javaembeddedserver javalanguage java3d jellytools jemmy jemmysupport jini jndi jpython junit j2eeserver lexer libs logger look makefile mdr metrics misc monitor multicompile nbbuild netbrowser objectbrowser openapi openide openidex openvms performance projects properties qa refactoring regsup remotefs rmi scripting serialversion schema2beans sim sourceeditor spellchecker sysprops tasklist tempwww testproject2 testtools testwww testwww2 text thecore tomcatint tools translatedfiles treefs ui usersguide utilities vcscore vcscvs vcsgeneric versioncontrol wasp web webcomponents webl workspaceswitcher www xml xmlbeans xtest
And last time I've got OOME happens using jdk1.4.2_03
I agree with Dan. Today I've tried to check out some source files and the netBeans crashed. I use built-in CVS client using cvstunnel pserver. Operating system Windows 2000, j2sdk1.4.2_03.
It looks like the missing cutting is not a problem. Even after checkout of "all" from cvs.netbeans.org, the checkout went O.K. and OOME was thrown during subsequent refreshes. The JTable takes some memory, but it's not the real problem. Therefore if you don't mind, I would set this as a duplicate of issue #41012. *** This issue has been marked as a duplicate of 41012 ***
:-)) I won't mind Martin. This Summary is little bit missleading IMHO, but initialy I thought it was caused by this