Henrik Olsson/IRD/Intentia is out of the office.
I will be out of the office starting 2003-07-11 and will not return until 2003-08-11. I am on vacation, I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: A performance patch for PDFInfo class
Hi Kevin.
Im sorry I got in to the dicussion att the wrong time...
There is NO difference in the garbage created by String a = foo +
bar; and StringBuffer xxx.append(foo).append(bar); They compile to
the same thing. Have a look at the pcode.
You are totaly right, in just adding strings together like:
public String testStringBufferChained() {
return (new StringBuffer().append(this )
.append(makeString(is ))
.append(a )
.append(makeString(test))).toString();
}
And there are nothing to gain.
But there are to many places where strings are added over and over to each other, and that was what I was talking about.
Butt never mind I have to read the mails better next time.
/Henrik
Kevin O'Neill [EMAIL PROTECTED]
2002-11-12 20:26
Please respond to fop-dev
To:FOP Developers [EMAIL PROTECTED]
cc:
Subject:Re: A performance patch for PDFInfo class
On Wed, 2002-11-13 at 02:25, Henrik Olsson wrote:
StringBuffer xxx.append(foo).append(bar);
understanding what the compiler does is the secret to optimizing
Strings.
Hi Kevin.
Its not an issue of what code is fastest here, its about creation and
destuction of objects.
There is NO difference in the garbage created by String a = foo +
bar; and StringBuffer xxx.append(foo).append(bar); They compile to
the same thing. Have a look at the pcode.
I have done several measurements on the fop to find the bottlenecks and
one of them are strings objects.
I think we agree on that gc is slow and one way to avoid gc its to use
StringBuffers instead of Strings while we are putting them together.
I have runned some profileing on the fop-0.20.4 and my tuned one (patch
14013) with the same fo-files.
And there are 680010 Strings in created in the fop-0.20.4 compared to
170395 Strings created in the tuned one, and this gives us a hint that the
gc dont have to run that offen and we can do some real work instead, speed
increased with 20-30%.
There is alot of += these should be removed as part of the move towards
1.0
Im also working on another preformence problems with properties and makers
but it takes a step from the fo-spec and needs to know some things about
the layout (pre parse the xsl before adding the xml data to it).
And it will increase the speed the bigger a layout gets...
And it can compete with commercial pruducts as StreamServe.
Se xsl chart at http://nohardcore.tripod.com/fop/FOP-test.zip
If You are interested in the code just say so.
Always.
/Henrik
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: A performance patch for PDFInfo class
StringBuffer xxx.append(foo).append(bar); understanding what the compiler does is the secret to optimizing Strings. Hi Kevin. Its not an issue of what code is fastest here, its about creation and destuction of objects. I have done several measurements on the fop to find the bottlenecks and one of them are strings objects. I think we agree on that gc is slow and one way to avoid gc its to use StringBuffers instead of Strings while we are putting them together. I have runned some profileing on the fop-0.20.4 and my tuned one (patch 14013) with the same fo-files. And there are 680010 Strings in created in the fop-0.20.4 compared to 170395 Strings created in the tuned one, and this gives us a hint that the gc dont have to run that offen and we can do some real work instead, speed increased with 20-30%. Im also working on another preformence problems with properties and makers but it takes a step from the fo-spec and needs to know some things about the layout (pre parse the xsl before adding the xml data to it). And it will increase the speed the bigger a layout gets... And it can compete with commercial pruducts as StreamServe. Se xsl chart at http://nohardcore.tripod.com/fop/FOP-test.zip If You are interested in the code just say so. /Henrik
Re: A performance patch for PDFInfo class
Keiron Liddle wrote: Surely functionality and design count before optimisations. Sad to here that, I think that it should be considered while you design and create functionality. Since the FOP are realy doing the job for me, just some prefomeance issue. /Henrik
Performance tuning
Hi, I have posted a patch in to the bugzilla (14013). It makes the fop_0.20.4 run aboute 20-30% faster. But if you think its not fast enough(i dont), i have som ideers how its possible to tweak the fop to preform real good. /Henrik performanceTuning.zip Description: Zip archive - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance tuning.
Nothing is not yet submitted, due to circumstances at work. I think I can send a part of it next week that gives aboute 30% faster fop. Henrik Venu Reddy [EMAIL PROTECTED] 2002-10-24 20:28 Please respond to fop-dev To:[EMAIL PROTECTED] cc: Subject:RE: Performance tuning. Hi, What is the current status of this performance tuning. Have the code changes been submitted and performance benefits verified. I really could use some speed improvements with fop, I have some very large reports 400/500 pages that are taking 5+ minutes to run. Thanks, Venu Reddy P.S: I am willing to apply the code changes to my version of fop(0.20.4), test it and submit the results on my large fo files. -Original Message- From: Martin Poeschl [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 17, 2002 11:48 PM To: [EMAIL PROTECTED] Subject: Re: Performance tuning. Henrik Olsson wrote: Hi. I have runned several performance tests on the FOP and and I have found out several bottle necks (especially in the PropertyListBuilder). Most things is about reducing gc and some others about not so well written code. The result of this tunings gives me a speed of 3 time faster than the original FOP. WOW!!! So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). could you make your patched version available somewhere??? if you don't have a server, just send it to my private mail and i'll put it in my home_dir at the apache server ;-) martin Henrik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance tuning.
Hi Jeremias. I have started the task to create diffs. But it makes it a bit complecated since there are about 10 diffrent things i have done to the code and some things affects more then 20 source files. So the question are: Do You want all the changes in one bunch or them separated in 10 diffrent groups that belongs together? Henrik Jeremias Maerki [EMAIL PROTECTED] 2002-10-17 10:56 Please respond to fop-dev To:[EMAIL PROTECTED] cc: Subject:Re: Performance tuning. Henrik, that sounds very interesting. Normal procedures for sending changes is to create a unified CVS diff file. You'll find some instructions following the URL below: http://xml.apache.org/source.html It's best if you post the two diff files (against the maintenance branch and the main branch) in a BugZilla entry, so it's not likely to get lost. One of the committers (I'll try to do it during the weekend if you can submit it it before then) will then review and apply the patch to the codebase. BugZilla is here: http://nagoya.apache.org/bugzilla/ Thanks a lot! I have runned several performance tests on the FOP and and I have found out several bottle necks (especially in the PropertyListBuilder). Most things is about reducing gc and some others about not so well written code. The result of this tunings gives me a speed of 3 time faster than the original FOP. So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Performance tuning.
Hi. I have runned several performance tests on the FOP and and I have found out several bottle necks (especially in the PropertyListBuilder). Most things is about reducing gc and some others about not so well written code. The result of this tunings gives me a speed of 3 time faster than the original FOP. So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). Henrik.
