Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!

Bug 51188

Summary: Populating of Output window for View Server Log action is slow
Product: platform Reporter: Antonin Nebuzelsky <anebuzelsky>
Component: Output WindowAssignee: Milos Kleint <mkleint>
Status: RESOLVED WONTFIX QA Contact: issues <issues.netbeans.org>
Priority: P3 CC: issues, ludo, tboudreau
Version: 4.xKeywords: PERFORMANCE
Target Milestone: 6.x   
Hardware: PC   
OS: Linux   
Whiteboard:
Issue Type: DEFECT Exception Report:
Bug Depends on: 55151    
Bug Blocks:    
Attachments: Hotspots as listed in optimizeit
sample module that tries to demonstrate teh problem

Description Antonin Nebuzelsky 2004-11-05 09:35:41 UTC
When you invoke View Server Log on a server node
in Runtime tab, Output window is populated with
the contents of the log. Populating the window is
slow, especially with the first invocation when
you can almost count the lines as they are being
printed out.
Comment 1 _ ludo 2004-11-09 23:45:48 UTC
This is wierd: not for me: i can see the entire content pretty fast...
Can you describe more your system? Can you reproduce this on another
system?
Comment 2 Antonin Nebuzelsky 2004-11-12 16:10:17 UTC
> Can you describe more your system?

Linux FC2, notebook Dell Latitude C840, 2GHz PIV, 1GB RAM.

The profiler shows that the top hotspot is NbWriter.println(). 
Perhaps non-buffered stream?

> Can you reproduce this on another system?

My other machine (W2K desktop) fails to show the log with an error
message about bad path to the log.
Comment 3 _ ludo 2004-11-12 16:12:25 UTC
I'll try on a linux system and will check for buffered streams.
Thanks.
Comment 4 Antonin Nebuzelsky 2004-11-12 16:13:47 UTC
Created attachment 18871 [details]
Hotspots as listed in optimizeit
Comment 5 _ ludo 2005-01-05 05:31:46 UTC
bad path error should be fixed now, so can you get the same date for
windows XP?
Seems to be a linux issue I think with JDK
Comment 6 Antonin Nebuzelsky 2005-01-05 14:07:49 UTC
Yes, I don't see the issue on Windows (W2K). View Server Log action
finishes almost instantly there.
Comment 7 _ ludo 2005-01-20 01:25:43 UTC
We are now truncating the log file to view only 10 000 max lines...
Does this improve the issue for long files?
Comment 8 _ ludo 2005-02-11 00:00:11 UTC
moving to core for further analysis.
Why output2.NbWriter.println would take so long only on linux systems?
Comment 9 _ ludo 2005-02-11 00:00:33 UTC
moving to core for further analysis.
Why output2.NbWriter.println would take so long only on linux systems?
Comment 10 Milos Kleint 2005-02-11 08:59:48 UTC
where can I check the sources for LogViewerSupport?
Comment 11 Milos Kleint 2005-02-11 10:18:34 UTC
a few general thoughts.
the output window apis are primarily focusing on the usecase where the
output is continually growing. That's what the Ui component also takes
into account, scrolling to the end of output all the time etc.

your usecase where you dump the whole log file at once into the output
is at least non-optimal use of the apis and one cannot expect a top
performance there. Ideally the log file should be passed to the output
window in one chunk. Now you are actually copying the log file into
another file, line-by-line and through the UI. That *has* to be slow..
Comment 12 _ ludo 2005-02-11 18:20:58 UTC
I'll send it to you. For now it is close source.
Comment 13 _ ludo 2005-02-11 18:25:46 UTC
1/ we are doing only tha last n lines so that the user has some
context: usally, when there are errors in the log, this is what the
user expects. (outside the IDE, the user would do a tail-f )

2/ on Windows XP, it is very very fast. So the issue is either in
Linux window manager or ui threading.
Comment 14 Milos Kleint 2005-02-28 15:05:51 UTC
in order to speed up the processing, we would need to enhance the
current API to include the usecase from enhancement #55151. That
cannot be done in 4.1 timeframe though. 

I cannot see any other solution to fix the problem. You could try not
to trim the output to fixed size. Given that the output UI component
always scrolls to the end, the user should be able to see the relevant
portion of the log.
Comment 15 _ tboudreau 2005-03-28 13:11:53 UTC
If you wanted to open up the API for this, cleanest might be to allow a client to supply their own pre-
populated implementation of Storage, or the file itself that should be displayed (note the output window 
expects UTF-16 - for throughput reasons, that's what its memory mapped buffer is).

Note if text wrapping is turned on, there will be some inevitable delay as wrap points are calculated.
Comment 16 Milos Kleint 2005-04-21 15:15:26 UTC
I have added some basic implementation of the direct log file viewing.
it's in core/output2 on branch ISSUE_51188. 
I added a IOProvider.showLogFile(String name, File logFile) method, the
implementation will memory map the log file itself without any copying.
There are 3 drawbacks to the current implementation now:
1. just UTF-16 supported as the log file's encoding. To support something else,
we will probably have to copy+encode the original log file into a different one.
2. the log file is assumed to grow only. Shrinking /deleting of the file is not
handled yet. TBD.
3. No hyperlinks in the text possible. As we avoid the println() calls on the
InputOutput instance, there's no way of adding hyperlinks. IMHO this is
unfixable and if hyperlinks are required we need to go some other way.

I've tried on a 40 MB file and the performance was acceptable (given the size of
the file)

Comment 17 Marian Mirilovic 2006-01-03 10:53:52 UTC
Too late for NB5.0, please reevaluate.
Comment 18 hatleye 2006-03-23 00:51:23 UTC
I am experiencing the same symptoms on windows XP (2GB RAM, 2.8 HT PENT) /
JDK1.4.2_10 running JBoss 4.0.3.  
Comment 19 hatleye 2006-03-23 00:54:55 UTC
I am experiencing the same symptoms on windows XP (2GB RAM, 2.8 HT PENT) /
JDK1.4.2_10 running JBoss 4.0.3.  I see this when I am running multiple JBoss
Appservers.  My development environment requires that I run 2 servers and the
output is very slow from the Appserver I use as the Servlet / jsp server.
Comment 20 _ tboudreau 2006-03-23 18:16:42 UTC
One simple suggestion:  From the profiler data, it looks like you're 
populating the output component from the AWT thread.  The IO APIs are designed 
to be thread-safe, and if it's a large log file, the AWT thread is probably 
the wrong place to make this call.

What's happening in println, IIRC, is that the code is searching for newlines 
in the text passed to it and calling itself back with individual lines.  That 
might not be terribly efficiently implemented - when I wrote it, I was 
expecting maybe a few hundred characters of text to be the common use case for 
that call, not a giant log file.

Comment 21 Milos Kleint 2006-08-07 13:30:58 UTC
Created attachment 32601 [details]
sample module that tries to demonstrate teh problem
Comment 22 Milos Kleint 2006-08-07 13:43:50 UTC
attached is a sample application that simulates what your module does.
1. print 15000 lines in a loop, count the time it took,
2. reset the output
3. print 15000 lines in look again, again mark how long it took.

both times are  comparable for me and reasobaly fast.

so my assumption is that the problem lies in the application server module -
closing as wontfix. please reopen with the sample app changed to demonstrate the
problem.


tboudreau: the awt stuf fin teh profiles picture is probably the output window
scrolling down and showing new lines..

hatleye: please file a separate issue agains the jboss support.
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo