You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Kelly Campbell <ca...@merlot.channelpoint.com> on 2001/03/31 15:25:06 UTC
some minor optimizing
Attached is a patch of some optimizations I've done and I wanted to have a
second opinion on whether or not I should commit this before or after the
0.18 release on Sunday. I focused on object allocations, and have been
very surprised at the results and how little effort it took.
Here's the top object allocations before I started when run on the
newlinktest.fo file:
10754 java.lang.String
6940 java.lang.StringBuffer
1879 java.lang.NumberFormatException
940 java.util.Vector
765 java.util.Hashtable$Entry
556 java.lang.FloatingDecimal
541 sun.io.CharToByteISO8859_1
522 java.util.Vector$1
446 java.util.Hashtable
And after:
6988 java.lang.String
2853 java.lang.StringBuffer
940 java.util.Vector
765 java.util.Hashtable$Entry
556 java.lang.FloatingDecimal
541 sun.io.CharToByteISO8859_1
522 java.util.Vector$1
333 java.util.HashMap$Entry
328 java.text.FieldPosition
Comparing the runtime for runtests.sh:
Before: 39 seconds
After: 24 seconds
So as you can see it was quite an improvement. Roughly 30% overall.
Most of the optimizations actually cleaned up the code, which is contrary
to the stereotype that optimizations add complexity. I only tackled the
simplest things though.
The patch should be safe to add now, but the one risk area I would like
someone else to double-check is the unicode support in
PDFRenderer.renderWordArea. I think I kept the equivalent functionality,
but I don't have any test cases to try for it.
Also, for those interested in how I profiled for object allocation, I'm
using the techniques described in O'Reilly's Java Performance Tuning book
by Jack Shirazi.
-Kelly
--
Kelly A. Campbell Software Engineer
<ca...@merlotxml.org> ChannelPoint, Inc.
<ca...@channelpoint.com> Colorado Springs, Co.
Re: some minor optimizing
Posted by Kelly Campbell <ca...@merlot.channelpoint.com>.
Like I said, the only part that concerns me is the unicode (actually CID
now that I'm looking closer at it). I will hold off until after the
release just to be safe. That was my original plan until I saw how simple
my changes are. But since I have been bitten by even the slightest
changes once before, I'll wait. :-)
On a semi-related topic, I added an explicit System.exit(0) at the end of
Fop.java's main() to work around a bug in the MacOS X JVM. This actually
got in the way of my memory tests, and it got me to thinking, some people
have been embedding Fop by calling our main(). Though that isn't the right
way to embed Fop, they're program will now exit when main is done.
I looked for other System.exit's and they're all over the place. This
means if something like a Servlet triggers a part of the code that handles
an error by exiting, their whole servlet engine exits. I will make this
one of the first things on my list to refactor. We should handle errors
via throwing exceptions, not exiting, even on the command line version.
I'm going to back out my change to main() right now just to be safe.
-Kelly
On Sat, Mar 31, 2001 at 02:30:00PM -0400, Arved Sandstrom wrote:
> At 06:25 AM 3/31/01 -0700, Kelly Campbell wrote:
> >Attached is a patch of some optimizations I've done and I wanted to have a
> >second opinion on whether or not I should commit this before or after the
> >0.18 release on Sunday. I focused on object allocations, and have been
> >very surprised at the results and how little effort it took.
>
> Just to be on the safe side I'd say we wait. I'd say that even if someone
> came through with some sensational new functionality right now, and had it
> ready to commit.
>
> It's your call - you know exactly what you did. If you want to commit, could
> you rtag the current stuff as "fop-0_18_1" beforehand, so we have a known
> point? Thanks.
>
> >Also, for those interested in how I profiled for object allocation, I'm
> >using the techniques described in O'Reilly's Java Performance Tuning book
> >by Jack Shirazi.
>
> Good book. :-) I have it also.
>
> Regards,
> Arved Sandstrom
>
> Fairly Senior Software Type
> e-plicity (http://www.e-plicity.com)
> Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
--
Kelly A. Campbell Software Engineer
<ca...@merlotxml.org> ChannelPoint, Inc.
<ca...@channelpoint.com> Colorado Springs, Co.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: some minor optimizing
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 06:25 AM 3/31/01 -0700, Kelly Campbell wrote:
>Attached is a patch of some optimizations I've done and I wanted to have a
>second opinion on whether or not I should commit this before or after the
>0.18 release on Sunday. I focused on object allocations, and have been
>very surprised at the results and how little effort it took.
Just to be on the safe side I'd say we wait. I'd say that even if someone
came through with some sensational new functionality right now, and had it
ready to commit.
It's your call - you know exactly what you did. If you want to commit, could
you rtag the current stuff as "fop-0_18_1" beforehand, so we have a known
point? Thanks.
>Also, for those interested in how I profiled for object allocation, I'm
>using the techniques described in O'Reilly's Java Performance Tuning book
>by Jack Shirazi.
Good book. :-) I have it also.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org