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.

Bug 40505 - CVS: Output doesn't cut command's result and uses JTable
Summary: CVS: Output doesn't cut command's result and uses JTable
Status: VERIFIED DUPLICATE of bug 41012
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcsgeneric (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Richard Gregor
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2004-02-26 07:18 UTC by dmladek
Modified: 2004-03-16 13:47 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dmladek 2004-02-26 07:18:57 UTC
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
Comment 1 dmladek 2004-02-26 07:20:28 UTC
I'm confident it has to be fix into NB3.6 release
Comment 2 Antonin Nebuzelsky 2004-02-26 07:41:40 UTC
Dane, please, use the keyword PERFORMANCE instead of putting this word
in the summary. Thanks.
Comment 3 Richard Gregor 2004-02-26 07:59:02 UTC
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. 
Comment 4 Milos Kleint 2004-02-26 08:28:18 UTC
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..
Comment 5 dmladek 2004-02-26 10:51:05 UTC
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?)


Comment 6 Martin Entlicher 2004-02-26 12:00:46 UTC
Yes, this is in vcsgeneric module. Also it affects only CVS
integration.
Comment 7 Richard Gregor 2004-02-26 15:10:52 UTC
One idea is to show table after command finishes and to show just
status of command while it is running.
Comment 8 Jiri Kovalsky 2004-02-26 16:07:11 UTC
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.
Comment 9 Richard Gregor 2004-02-26 16:25:07 UTC
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!
Comment 10 Richard Gregor 2004-02-27 09:32:36 UTC
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.
Comment 11 dmladek 2004-02-27 10:48:45 UTC
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... 
Comment 12 dmladek 2004-03-11 16:19:51 UTC
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

Comment 13 dmladek 2004-03-11 16:28:14 UTC
And last time I've got OOME happens using jdk1.4.2_03
Comment 14 Peter Pis 2004-03-12 14:58:34 UTC
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. 

Comment 15 Martin Entlicher 2004-03-16 13:31:55 UTC
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 ***
Comment 16 dmladek 2004-03-16 13:47:31 UTC
:-)) I won't mind Martin. This Summary is little bit missleading IMHO,
but initialy I thought it was caused by this