• Post Reply Bookmark Topic Watch Topic
  • New Topic

Performance output to Browser

 
Jason Stortz
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Peers and Teachers,
I am wondering exactly how the underside of out.println() works in a Servlet. I use the following to setup my out object:

Then, the code I am maintaining makes numerous calls to out.println() to generate the webpage. I am wondering if it would be faster to put the page into a StringBuffer object and at the end use out.println(buf.toString()); instead of using a lot of out.println() method calls.
So, how does out.println() work? Is it take the data and storing it in a buffer of its own before putting it out to the page? If so, out.println is one call, internal storage to buffer is another call, and simply putting in a buffer in the code and making one call to println seems better.
I am guessing about 300 or more calls to println method are made, so any performance gain I can garnish here is great.
Thanks,
Jason
SCJP
 
Jason Stortz
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
More Info:
I have been looking through the javadocs on the PrintWriter class. It looks to me as the general flow that occurs is as follows.
I call println(s) with some String object s.
JavaDoc states println acts like print(s) and then println() (with println() method being a call by itself that outputs the line separator).
The print(s) string converts String to bytes and uses a similar method to write(int) to write out the bytes.
THUS: method flow is println(s)->print(s)->convertToBytes(S)->writeBytes()->println().
That is at least 5 method calls. It is really looking to me like it would be so much faster to just use buf.append(s) and only use out.println() at the end.
Can anyone offer any other thoughts, etc?
 
Jason Stortz
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried modeling a very simple test on StringBuffer and System.out.println. If the line to be printed out is very small, say only one word, the buffer type wins, if the output is a long line, the println method wins.

Hmm. Well, here is the test code.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A couple of points.
  • Method calls are cheap. Unless you know that the overhead is significant ("know" as in "profiler") you should never compromise your application in an attempt to optimise them.
  • The StringBuffer needs to be allocated and probably grown a few times - this is an expensive operation. You could of course allocate a worst-case buffer size, but that will greatly increase the memory footprint of each request and decrease the scalability of your application.
  • You can solve this problem by using a BufferedWriter instead of a StringBuffer. However, if this really makes a measurable difference then, assuming the vendor did a proper job, that is exactly what is sitting behind the PrintWriter and your buffer would just be so much additional overhead. If not, then the application server buffer is residing at the Stream level.

  • HTH
    - Peter
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jason Stortz:
[...]If the line to be printed out is very small, say only one word, the buffer type wins, if the output is a long line, the println method wins.
I'm not convinced that this is an accurate model of what happens inside an application server. Anyway, you are probably seeing the effects of growing the StringBuffer() for longer line sizes - try giving it a default size. Then up the number of iterations, give the garbage collector something to do
- Peter

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!