Re: [iText-questions] performance follow up
Hello,
On Apr 23, 2010, at 10:50 PM, trumpetinc wrote:
Don't know if it'll make any difference, but the way you are reading the file
is horribly inefficient. If the code you wrote is part of your test times,
you might want to re-try, but using this instead (I'm just tossing this
together - there might be type-os):
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buf = new byte[8092];
int n;
while ((n = is.read(buf)) = 0) {
baos.write(buf, 0, n);
}
return baos.toByteArray();
I tried your suggestion above and made no significative difference compared to
doing the loading from iText. The fastest I could get my use case to work using
this pre-loading concept was by loading the whole file in one shot using the
code below.
Applying the cumulative patch plus preloading the whole PDF using the code
below, my original test-case now performs 7.74% faster than before, roughly 22%
away from competitor now ...
btw the average response time numbers I was getting:
- average response time of 77ms original unchanged test-case from the office
multi-processor-multi-core workstation
- average response time of 15ms original unchanged test-case from home using my
MBP
I attribute the huge difference between those two similar experiments mainly to
having an SSD drive in my MBP ... the top Host spots reported from the profiler
are related one way or another to IO so would be no wonder that with an SSD
drive the response time improves by a factor of 5x. There are other differences
though e.g. OS, JVM version.
Best regards,
Giovanni
private static byte[] file2ByteArray(String filePath) throws Exception {
InputStream input = null;
try {
File file = new File(filePath);
input = new BufferedInputStream(new FileInputStream(filePath));
byte[] buff = new byte[(int) file.length()];
input.read(buff);
return buff;
}
finally {
if (input != null) {
input.close();
}
}
}
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
From: brave...@gmail.com
Date: Sat, 24 Apr 2010 13:05:26 +0200
To: itext-questions@lists.sourceforge.net
Subject: Re: [iText-questions] performance follow up
Hello,
On Apr 23, 2010, at 10:50 PM, trumpetinc wrote:
Don't know if it'll make any difference, but the way you are reading the file
is horribly inefficient. If the code you wrote is part of your test times,
you might want to re-try, but using this instead (I'm just tossing this
together - there might be type-os):
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buf = new byte[8092];
int n;
while ((n = is.read(buf))= 0) {
baos.write(buf, 0, n);
}
return baos.toByteArray();
I tried your suggestion above and made no significative difference compared
to doing the loading from iText. The fastest I could get my use case to work
using this pre-loading concept was by loading the whole file in one shot
using the code below.
If as indicated below you are generally IO limited, don't throw
the code out yet. If you must copy data you want to use array
based methods as often as possible but the first preference
is to avoid copies unless of course you are strategicly
preloading or something.
I often just turn everything into a byte array but
obviously this doesn't scale too well unless you are content to let
VM do your swapping for you. Ideally you would just load what you
need in a just-in-time fashion to avoid tying up idle RAM.
Applying the cumulative patch plus preloading the whole PDF using the code
below, my original test-case now performs 7.74% faster than before, roughly
22% away from competitor now ...
btw the average response time numbers I was getting:
- average response time of 77ms original unchanged test-case from the office
multi-processor-multi-core workstation
- average response time of 15ms original unchanged test-case from home using
my MBP
I attribute the huge difference between those two similar experiments mainly
to having an SSD drive in my MBP ... the top Host spots reported from the
profiler are related one way or another to IO so would be no wonder that with
an SSD drive the response time improves by a factor of 5x. There are other
differences though e.g. OS, JVM version.
Multi-proc and disk cache can cause some confusions. I wouldn't ignore
task manager for some initial investigations- if the CPU drops and disk
light comes on you are likely to be disk limited. With IO it is easy
to get nickel-and-dimed to death as everyone who relays the data
can be low on profile chart but it adds up. Wall-clock times are least
susceptible to manipulation and may be best for A-B comparisons
if you have control over other stuff running on machine ( cash flow versus
pro-forma earnings LOL). If you can subclass
the random access file thing you may be able to first collect statistics
and then write something that can see into the future a few milliseconds.
All the generic caches work on past results, things like MRU except maybe the
prefetch
which assumes you will continue to do sequential memory accesses. If you
are in a posittion to make forward looking statements that have a material
impact on your performance you ( ROFL) you may be able to
do much better.
Best regards,
Giovanni
private static byte[] file2ByteArray(String filePath) throws Exception {
InputStream input = null;
try {
File file = new File(filePath);
input = new BufferedInputStream(new FileInputStream(filePath));
byte[] buff = new byte[(int) file.length()];
input.read(buff);
return buff;
}
finally {
if (input != null) {
input.close();
}
}
}
_
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
If the file is being entirely pre-loaded, then I doubt that IO blocking is a
significant contributing factor to your test.
I think that the best clue here may be the difference between performance
with form flattening and without form flattening. Just to confirm, am I
right in saying that iText outperforms the competitor by a significant
amount in the non-flattening scenario? If that's the case, then it seems
like we should see significant differences in the profiling results between
the flattening and non-flattening scenarios in iText.
Would you be willing to post the profiling results for both cases so we can
see which code paths are consuming the most runtime in each?
Another possibility if the profiling results show similar hotspots is that
the form flattening algorithms in iText are using the hotspot areas a lot
more than in the non-flattening case. There may be a bunch of redundant
reads or something in the flattening case.
Let's take a look at the profiling results and see if we can draw any
conclusions about where to go next.
BTW - which profiler are you using? Are you able to expand each of the
hotspot code paths and see the actual call path that is causing the
bottleneck? I use jvvm, and the results of expanding the hotspot call trees
can be quite illuminating.
What I really would like is to get ahold of your two benchmark tests (with
and without flattening) so I can run it on my system - do you have anything
you can package up and share?
- K
Giovanni Azua-2 wrote:
Hello,
On Apr 23, 2010, at 10:50 PM, trumpetinc wrote:
Don't know if it'll make any difference, but the way you are reading the
file
is horribly inefficient. If the code you wrote is part of your test
times,
you might want to re-try, but using this instead (I'm just tossing this
together - there might be type-os):
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buf = new byte[8092];
int n;
while ((n = is.read(buf)) = 0) {
baos.write(buf, 0, n);
}
return baos.toByteArray();
I tried your suggestion above and made no significative difference
compared to doing the loading from iText. The fastest I could get my use
case to work using this pre-loading concept was by loading the whole file
in one shot using the code below.
Applying the cumulative patch plus preloading the whole PDF using the code
below, my original test-case now performs 7.74% faster than before,
roughly 22% away from competitor now ...
btw the average response time numbers I was getting:
- average response time of 77ms original unchanged test-case from the
office multi-processor-multi-core workstation
- average response time of 15ms original unchanged test-case from home
using my MBP
I attribute the huge difference between those two similar experiments
mainly to having an SSD drive in my MBP ... the top Host spots reported
from the profiler are related one way or another to IO so would be no
wonder that with an SSD drive the response time improves by a factor of
5x. There are other differences though e.g. OS, JVM version.
Best regards,
Giovanni
private static byte[] file2ByteArray(String filePath) throws Exception {
InputStream input = null;
try {
File file = new File(filePath);
input = new BufferedInputStream(new FileInputStream(filePath));
byte[] buff = new byte[(int) file.length()];
input.read(buff);
return buff;
}
finally {
if (input != null) {
input.close();
}
}
}
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list:
http://1t3xt.info/tutorials/keywords/
--
View this message in context:
http://old.nabble.com/performance-follow-up-tp28322800p28352147.html
Sent from the iText - General mailing list archive at Nabble.com.
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Isn't there something in PDF about linearization? ( the term
comes up as a suggestion on google, LOL). How
can you compare the two resulting pdf's in terms of
dynamic attributes or arbitrary ordering or some items- given issues with IO
and access
patterns this could be an issue. In fact, you could
even imagine that if you could reorder somethings
you get win-win for creation and future rendering time.
What is the extent of the freedom here? It sounds like
any hints you would generate for reader could be used
during document manipulation in itext.
Date: Sat, 24 Apr 2010 11:59:14 -0700
From: forum_...@trumpetinc.com
To: itext-questions@lists.sourceforge.net
Subject: Re: [iText-questions] performance follow up
If the file is being entirely pre-loaded, then I doubt that IO blocking is a
significant contributing factor to your test.
I think that the best clue here may be the difference between performance
with form flattening and without form flattening. Just to confirm, am I
right in saying that iText outperforms the competitor by a significant
amount in the non-flattening scenario? If that's the case, then it seems
like we should see significant differences in the profiling results between
the flattening and non-flattening scenarios in iText.
Would you be willing to post the profiling results for both cases so we can
see which code paths are consuming the most runtime in each?
Another possibility if the profiling results show similar hotspots is that
the form flattening algorithms in iText are using the hotspot areas a lot
more than in the non-flattening case. There may be a bunch of redundant
reads or something in the flattening case.
Let's take a look at the profiling results and see if we can draw any
conclusions about where to go next.
BTW - which profiler are you using? Are you able to expand each of the
hotspot code paths and see the actual call path that is causing the
bottleneck? I use jvvm, and the results of expanding the hotspot call trees
can be quite illuminating.
What I really would like is to get ahold of your two benchmark tests (with
and without flattening) so I can run it on my system - do you have anything
you can package up and share?
- K
Giovanni Azua-2 wrote:
Hello,
On Apr 23, 2010, at 10:50 PM, trumpetinc wrote:
Don't know if it'll make any difference, but the way you are reading the
file
is horribly inefficient. If the code you wrote is part of your test
times,
you might want to re-try, but using this instead (I'm just tossing this
together - there might be type-os):
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buf = new byte[8092];
int n;
while ((n = is.read(buf))= 0) {
baos.write(buf, 0, n);
}
return baos.toByteArray();
I tried your suggestion above and made no significative difference
compared to doing the loading from iText. The fastest I could get my use
case to work using this pre-loading concept was by loading the whole file
in one shot using the code below.
Applying the cumulative patch plus preloading the whole PDF using the code
below, my original test-case now performs 7.74% faster than before,
roughly 22% away from competitor now ...
btw the average response time numbers I was getting:
- average response time of 77ms original unchanged test-case from the
office multi-processor-multi-core workstation
- average response time of 15ms original unchanged test-case from home
using my MBP
I attribute the huge difference between those two similar experiments
mainly to having an SSD drive in my MBP ... the top Host spots reported
from the profiler are related one way or another to IO so would be no
wonder that with an SSD drive the response time improves by a factor of
5x. There are other differences though e.g. OS, JVM version.
Best regards,
Giovanni
private static byte[] file2ByteArray(String filePath) throws Exception {
InputStream input = null;
try {
File file = new File(filePath);
input = new BufferedInputStream(new FileInputStream(filePath));
byte[] buff = new byte[(int) file.length()];
input.read(buff);
return buff;
}
finally {
if (input != null) {
input.close();
}
}
}
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list:
http://1t3xt.info/tutorials/keywords/
--
View this message in context:
http://old.nabble.com/performance-follow-up-tp28322800p28352147.html
Sent from the iText - General mailing list archive at Nabble.com
Re: [iText-questions] performance follow up
On Apr 24, 2010, at 8:59 PM, trumpetinc wrote: If the file is being entirely pre-loaded, then I doubt that IO blocking is a significant contributing factor to your test. After I did the entire pre-loading, taking the entire file at once the benchmarks look better yes, meaning there is some bottleneck in the way itext handles the loading of the PDF files. Besides changing to a different storage i.e. from non SSD in the office to SSD in my laptop shows a performance improvement by a factor of 5x, of course there could be other reasons but I would be willing to bet that this 5x faster is by a high margin due to the fast SSD. If there is something SSD are really good at is Random access and iText is doing that and a lot. Benchmarking the alternative in my laptop shows: alternative mean RT: 18ms itext mean RT: 14ms So in my laptop itext is faster than the alternative ... why? I think because of random access. If itext was doing a lot of random access it could slow it down in a non-SSD drive like the one I have in the office.I have to benchmark again itext in the office to see how it performs with the new load the entire file strategy. Because of these variations I will setup the experiment in the actual hardware where it will be deployed. I think that the best clue here may be the difference between performance with form flattening and without form flattening. Just to confirm, am I right in saying that iText outperforms the competitor by a significant amount in the non-flattening scenario? If that's the case, then it seems like we should see significant differences in the profiling results between the flattening and non-flattening scenarios in iText. Would you be willing to post the profiling results for both cases so we can see which code paths are consuming the most runtime in each? I posted this yesterday, see http://old.nabble.com/more-on-performance-td28346917.html - FOOTER 4x shows the Hot spot profiler results in the loading and flattening case - HEADER 4x shows the Hot spot profiler results for the loading only BTW - which profiler are you using? Are you able to expand each of the hotspot code paths and see the actual call path that is causing the bottleneck? I use jvvm, and the results of expanding the hotspot call trees can be quite illuminating. I am using JProfiler. I can expand the Hotspots, it shows the full call trees leading to the Hot spot. What I really would like is to get ahold of your two benchmark tests (with and without flattening) so I can run it on my system - do you have anything you can package up and share? I will prepare it for you ... Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello Mike, On Apr 23, 2010, at 12:55 AM, Mike Marchywka wrote: Mark Twain gets to the front so quickly. Again, I'm not suggesting you did anything wrong or bad, I haven't actually checked numbers or given the specific test a lot of thought- 9 data points is usually not all that conclusive in any case and I guess that's my point. There are 10 means, each mean comes from 1K data points, so there are 10K data points for each version tested, not just 9 Unlike other tests of significance, t-test doesn't need a large number of observations. It is actually this case of few observations e.g. 10 means one of its main use-cases. Indeed one would need to check the assumptions of independence and normality. Looking at the response times though looks ok normal distribution ... I owe you the scatter and QQ plots. I really would not expect a Gamma going on but I might be wrong :) Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello Paulo, On Apr 22, 2010, at 11:43 PM, Paulo Soares wrote: FYI I already use a table to map the char to the result for the delimiter testing and the speed improvement was zero in relation to plain comparisons. Paulo You are right ... changing to a table makes no difference. I checked this with the profiler and the results stay the same. Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
On Apr 22, 2010, at 11:18 PM, trumpetinc wrote: I like your approach! A simple if (ch 32) return false; at the very top would give the most bang for the least effort (if you do go the bitmask route, be sure to include unit tests!). Doing this change spares approximately two seconds out of the full workload so now shows 8s instead of 10s and isWhitespace stays at 1%. The numbers below include two extra changes: the one from trumpetinc above and migrating all StringBuffer references to use instead StringBuilder. The top are now: PRTokeniser.nextToken 8% 77s 19'268'000 invocations RandomAccessFileOrArray.read 6% 53s 149'047'680 invocations MappedRandomAccessFile.read 3% 26s 61'065'680 invocations PdfReader.removeUnusedCode 1% 15s 6000 invocations PdfEncodings.convertToBytes 1% 15s5'296'207 invocations PRTokeniser.nextValidToken1%12s 9'862'000 invocations PdfReader.readPRObject 1%10s 5'974'000 invocations ByteBuffer.append(char) 1%10s 19'379'382 invocations PRTokeniser.backOnePosition 1%10s 17'574'000 invocations PRTokeniser.isWhitespace 1%8s 35'622'000 invocations A bit further down there is ByteBuffer.append_i that often needs to reallocate and do an array copy thus the expensive ByBuffer.append(char) above ... I am playing right now with bigger initial sizes e.g. 512 instead of 127 ... Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
From: brave...@gmail.com Date: Fri, 23 Apr 2010 12:23:50 +0200 To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up Hello Mike, On Apr 23, 2010, at 12:55 AM, Mike Marchywka wrote: Mark Twain gets to the front so quickly. Again, I'm not suggesting you did anything wrong or bad, I haven't actually checked numbers or given the specific test a lot of thought- 9 data points is usually not all that conclusive in any case and I guess that's my point. There are 10 means, each mean comes from 1K data points, so there are 10K data points for each version tested, not just 9 I thought you had 9 test cases but 9 or 10 doesn't matter much. Unlike other tests of significance, t-test doesn't need a large number of observations. It is actually this case of few observations e.g. 10 yeah, personally I've never liked nonparametrics and other approaches that magically work with a few samples. Generally they treat the small sample cases by dealing with outliers ( outliars LOL? ) more gracefully. However, if you make some assumptions about population statistics and run monte carlo you can see how often your 9 or 10 points with your chosen test lead to misleading results. This is a bit of an inverse problem- you have data with contributions from many sources ( ie noise ) and you are trying to estimate some underlying clean number- known approaches to this have limits. means one of its main use-cases. Indeed one would need to check the assumptions of independence and normality. Looking at the response times Cache warmness could lead to lots of run-to-run dependence depending on what you measure and I know personally I see this with second invokation of various command line programs. If as you suggest the distro is normal maybe it is just a bunch of random junk but sometimes you see multi-modal and each peak is probably due to something interesting. In any case, the point here is to make the code faster and use the stats or whatever other meaures you have to point the way. Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/ _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
From: brave...@gmail.com Date: Fri, 23 Apr 2010 12:55:03 +0200 To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up On Apr 22, 2010, at 11:18 PM, trumpetinc wrote: I like your approach! A simple if (ch 32) return false; at the very top would give the most bang for the least effort (if you do go the bitmask route, be sure to include unit tests!). Doing this change spares approximately two seconds out of the full workload so now shows 8s instead of 10s and isWhitespace stays at 1%. The numbers below include two extra changes: the one from trumpetinc above and migrating all StringBuffer references to use instead StringBuilder. The top are now: PRTokeniser.nextToken 8% 77s 19'268'000 invocations RandomAccessFileOrArray.read 6% 53s 149'047'680 invocations MappedRandomAccessFile.read 3% 26s 61'065'680 invocations PdfReader.removeUnusedCode 1% 15s 6000 invocations PdfEncodings.convertToBytes 1% 15s 5'296'207 invocations PRTokeniser.nextValidToken 1% 12s 9'862'000 invocations PdfReader.readPRObject 1% 10s 5'974'000 invocations ByteBuffer.append(char) 1% 10s 19'379'382 invocations PRTokeniser.backOnePosition 1% 10s 17'574'000 invocations PRTokeniser.isWhitespace 1% 8s 35'622'000 invocations A bit further down there is ByteBuffer.append_i that often needs to reallocate and do an array copy thus the expensive ByBuffer.append(char) above ... I am playing right now with bigger initial sizes e.g. 512 instead of 127 ... I had a draft message I never sent regarding this. Essentially don't call append, find the end then call String(byte[],offset,length) or better ( this gets involved ) don't make temp strings just pass around indexes ( you need to give this some thought, but my post was getting quite confusing so I scrapped it). Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/ _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
this is draft I mentioned earlier, it was getting a bit convoluted due to over qualifiying each assertion but if you are using append's a lot, consider the basic idea of finding the delims FIRSt then doing one or more array ops or avoiding string creating altogether. I don't have any idea what you are doing with these strings you parse but if building dictionaries, consider things like the following. On large dictionaries with coherent access patterns , hash tables may not be as efficient as sorted things with the right indexing ( this may not be apparent until you start VM thrashing but if you have ordered queries on static dictionaries, a sparse hash can make a mess of a cache compared to a well thought out b-search on a compact representation of your strings). I'm not entirely sure the multi-pass approach I try to outline below has a lot of merit but you would need to consider some issues along these lines. From: brave...@gmail.com Date: Fri, 23 Apr 2010 12:27:42 +0200 To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up Hello Paulo, On Apr 22, 2010, at 11:43 PM, Paulo Soares wrote: FYI I already use a table to map the char to the result for the delimiter testing and the speed improvement was zero in relation to plain comparisons. Paulo You are right ... changing to a table makes no difference. I checked this with the profiler and the results stay the same. Why does that method take an int param vs char or better a byte? Implicit casts are not normally free, probably look up table needs to convert array index to int anyway but if you are doing specific booleans comparing byte to byte you may be able to avoid some JVM junk. In any case, the method code could hide that if needed at all. As should be clear, I'm not familiar with the code and don't have it in from of me but a few thoughts. Often reordering operations can help but it may not be obvious a priori which approach is best. Multiple passes are generally bad compared to working on blocks that preserve locality and maximize low level memory cache hits. However, due to other issues it coud make sense, or at least multiple passes in small blocks. You could consider inlining this method in one place along with any similar ones and making a classification pass during which you scan each char in your input data and create a class for it. Then make a second pass through your now huge data in which each char is followed by its class and then have processing based on a big switch statement that switches on the class and whatever state info you have made. Or, consider building a table of whitespace locations on your first pass etc etc. If you are currently going through calling something like an append(char) method on each char, you may be better off finding limits and creating a new string with String(byte[]. offset, length) etc. Also, presumably you find token limits and then make strings, it is possible to avoid creating strings at all and just pass around indexes into a byte array? This may require massive code changes all over and depending on what you do with the strings may or may not help much as many common operations may be expected to be opimitzed in native code for strings. However, If you have huge hash tables each look up may be cheap to compute but each one also trashes the memory cache. You may be better off with ordered index structs that you can implement in java with byte[] more easily than strings. And, of course, don't ignore obvious data dependent optimizations. If you have strings with long common prefix like, http://www then removing this from compares could be a big help with memory and speed. Best regards, Giovanni _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Yes - it needs to be int. Regardless, we need to focus on the things that are actually consuming run time, and this method isn't one of them (no matter how much it could be optimized). Mike Marchywka-2 wrote: does this have to be int vs char or byte? I think earlier I suggested operating on byte[] instead of making a bunch of temp strings but I don't know the context well enough to know if this makes sense. Certainly demorgan can help but casts and calls are not free either. Also, maybe hotspot runtime has gotten better but I have found in the past that look up tables can quickly become competititve with bit operators ( if your param is byte instead of int, a 256 entry table can tell you if the byte is a member of which classes). -- View this message in context: http://old.nabble.com/performance-follow-up-tp28322800p28343789.html Sent from the iText - General mailing list archive at Nabble.com. -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Date: Fri, 23 Apr 2010 09:43:08 -0700 From: forum_...@trumpetinc.com To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up Yes - it needs to be int. Regardless, we need to focus on the things that So you are doing everything internally with 32 bit chars? Not a big deal but if these are mostly zero there may be better ways to represent and save memory. You may say, well RAM is cheap but that doesn't matter since low level caches are fixed but I guess you can get a bigger disk and say VM is unlimited. are actually consuming run time, and this method isn't one of them (no matter how much it could be optimized). The only person with data claimed otherwise :) Mike Marchywka-2 wrote: does this have to be int vs char or byte? I think earlier I suggested operating on byte[] instead of making a bunch of temp strings but I don't know the context well enough to know if this makes sense. Certainly demorgan can help but casts and calls are not free either. Also, maybe hotspot runtime has gotten better but I have found in the past that look up tables can quickly become competititve with bit operators ( if your param is byte instead of int, a 256 entry table can tell you if the byte is a member of which classes). -- View this message in context: http://old.nabble.com/performance-follow-up-tp28322800p28343789.html Sent from the iText - General mailing list archive at Nabble.com. -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/ _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
This tells us that the focus needs to be on PRTokeniser and RAFOA. For what it's worth, these have also shown up as the bottlenecks in profiling I've done in the parser package (not too surprising). I'll discuss each in turn: RandomAccessFileOrArray - I've done a lot of thinking on this one in the past. This is an interesting class that can have massive impact on performance, depending on how you use it. For example, if you load your source PDF entirely into memory, and pass the bytes into RAFOA, it will remove IO bottlenecks. Giovanni - if your source PDFs are small enough, you might want to try this, just to get a feel for the impact that IO blocking is having on your results (read entire PDF into byte[] and use PdfReader(byte[])) The next thing that I looked at was buffering (a naive use of RandomAccessFile is horrible for performance, and significant gains can be had by implementing a paging strategy). I actually implemented a paging RandomAccessFile and started work on rolling it into RAFOA last year, but my benchmarks showed that the memory mapped strategy that RAFOA uses had equivalent performance to the paging RAF implementation. These tests weren't conclusive, so there may still be some things to learn in this area. The one problem with the memory mapped strategy (in it's current implementation) is that really big source PDFs still can't be loaded into memory. This could be addressed by using a paging strategy on the mapped portion of the file - probably keep 10 or 15 mapped regions in an MRU cache (maybe 1MB in size each). For reference, the ugly (really ugly) hack that determines whether RAFOA will use memory mapped IO is the Document.plainRandomAccess static public variable (shudder). So what about the code paths in PRTokeniser.nextToken()? We've got a number of tight loops reading individual characters from the RAFOA. If the backing source isn't buffered, this would be a problem, but I don't know that is really the issue here (it would be worth measuring though...) The StringBuffer could definitely be replaced with a StringBuilder, and it could be re-used instead of re-allocating for each call to nextTokeen() (this would probably help quite a bit, as I'll bet the default size of the backing buffer has to keep growing during dictionary reads). Another thing that could make a difference is ordering of the case and if's - for example, the default: branch turns around and does a check for (ch == '-' || ch == '+' || ch == '.' || (ch = '0' ch = '9'). Changing this to be: case '-': case '+': case '.': case '0': ... case '9': May be better. The loops that check for while (ch != -1 ((ch = '0' ch = '9') || ch == '.')) could also probably be optimized by removing the ch != -1 check - the other conditions ensure that the loop will escape if ch==-1 It might be interesting to break the top level parsing branches into separate functions so the profiler tell us which of these main branches is consuming the bulk of the run time. Those are the obvious low hanging fruit that I see. Final point: I've seen some comments suggesting inlining of some code. Modern VMs are quite good at doing this sort of inlining automatically - a test would be advisable before worrying about it too much. Having things split out actually makes it easier to use a profiler to determine where the bottleneck is. One thing that is quite clear here is that we need to have some sort of benchmark that we can use for evaluation - for example, if I had a good benchmark test, I would have just tried the ideas above to see how they fared. - K Giovanni Azua-2 wrote: On Apr 22, 2010, at 11:18 PM, trumpetinc wrote: I like your approach! A simple if (ch 32) return false; at the very top would give the most bang for the least effort (if you do go the bitmask route, be sure to include unit tests!). Doing this change spares approximately two seconds out of the full workload so now shows 8s instead of 10s and isWhitespace stays at 1%. The numbers below include two extra changes: the one from trumpetinc above and migrating all StringBuffer references to use instead StringBuilder. The top are now: PRTokeniser.nextToken 8% 77s 19'268'000 invocations RandomAccessFileOrArray.read 6% 53s 149'047'680 invocations MappedRandomAccessFile.read 3% 26s 61'065'680 invocations PdfReader.removeUnusedCode 1% 15s 6000 invocations PdfEncodings.convertToBytes 1% 15s5'296'207 invocations PRTokeniser.nextValidToken1%12s 9'862'000 invocations PdfReader.readPRObject 1%10s 5'974'000 invocations ByteBuffer.append(char) 1%10s 19'379'382 invocations PRTokeniser.backOnePosition 1%10s 17'574'000 invocations PRTokeniser.isWhitespace 1%8s 35'622'000 invocations A bit further down there is ByteBuffer.append_i that often
Re: [iText-questions] performance follow up
Date: Fri, 23 Apr 2010 10:29:43 -0700 From: forum_...@trumpetinc.com To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up This tells us that the focus needs to be on PRTokeniser and RAFOA. For what it's worth, these have also shown up as the bottlenecks in profiling I've done in the parser package (not too surprising). I'll discuss each in turn: RandomAccessFileOrArray - I've done a lot of thinking on this one in the past. This is an interesting class that can have massive impact on performance, depending on how you use it. For example, if you load your source PDF entirely into memory, and pass the bytes into RAFOA, it will remove IO bottlenecks. I mentioned IO early on as a neglected task where you just pull some generic thing out and let it hand you a byte at a time, clearly if you know your access pattern and can make it coherent you stand to gain a lot. Caching and VM can only guess what you will do next, you may know better :) The one problem with the memory mapped strategy (in it's current implementation) is that really big source PDFs still can't be loaded into memory. This could be addressed by using a paging strategy on the mapped You can have alt implementations in the mean time if you know size a priori. Ideally you would like to be able to operate on a stream and scrap random access. will use memory mapped IO is the Document.plainRandomAccess static public variable (shudder). As if 2 people would use this at the same time ROFL :) Its bad enough you don't have globals... So what about the code paths in PRTokeniser.nextToken()? We've got a number of tight loops reading individual characters from the RAFOA. If the backing source isn't buffered, this would be a problem, but I don't know that is really the issue here (it would be worth measuring though...) The StringBuffer could definitely be replaced with a StringBuilder, and it could be re-used instead of re-allocating for each call to nextTokeen() (this would probably help quite a bit, as I'll bet the default size of the backing buffer has to keep growing during dictionary reads). Again, why even do this? Find the delimeters and, if you must make a string make it only when you know start and end, don't keep looping with append(char) no matter how nice the source code looks. If you can use anything with [] in the sig it stands a chance of being faster. Pass as much a priori info to the library classes as you can- append means whoops I found ANOTHER thing to add when you already have the data just say here is the string I need. And unless you actually need the tokens as strings, consider just returning indexes or something. You may or may not need strings all the time, it may be possible to use int[] or something. Another thing that could make a difference is ordering of the case and if's - for example, the default: branch turns around and does a check for (ch == '-' || ch == '+' || ch == '.' || (ch= '0' ch = '9'). Changing this to be: case '-': case '+': case '.': case '0': ... case '9': Actually optimizing compilers do stuff like this- you have some known, assumed, or measured branching probability and make the common ones faster ( minimize expectation value of execution time). I haven't checked lately but IIRC the compiler tries to make a switch into a jump table. May be better. The loops that check for while (ch != -1 ((ch= '0' ch = '9') || ch == '.')) could also probably be optimized by removing the ch != -1 check - the other conditions ensure that the loop will escape if ch==-1 It might be interesting to break the top level parsing branches into separate functions so the profiler tell us which of these main branches is consuming the bulk of the run time. Those are the obvious low hanging fruit that I see. Final point: I've seen some comments suggesting inlining of some code. Modern VMs are quite good at doing this sort of inlining automatically - a test would be advisable before worrying about it too much. Having things split out actually makes it easier to use a profiler to determine where the bottleneck is. One thing that is quite clear here is that we need to have some sort of benchmark that we can use for evaluation - for example, if I had a good benchmark test, I would have just tried the ideas above to see how they fared. If you have a set of benchmarks, you can afford to measure them according to things you think will impact execution time. then, with enough, you can fit execution time to your measurements using alt pieces of code. This is where you start find statistics helpful ( pdf with value X for attribute A incurs a time penalty of n seconds per increment of X ). FWIW, there is also something about identical, indepdent entities for a statistical sample. If you can measure these they aren't identical. The top are now
Re: [iText-questions] performance follow up
Nah - I'm not saying that memory is cheap (or that cache misses aren't important) - just saying that int - char casting isn't the culprit here. The parser is a really low level algorithm that is responsible for reading int from the bytes of a file and figuring out the appropriate value to convert them to. Sometimes it's a char, sometimes not. By the time the results of the parse are pulled from the parser, they are not ints anymore. It's not like we are carrying around a massive block of int[] to represent a string or anything like that. The profiling results from Giovanni indicate that the call to isWhitespace accounts for less than 1% of runtime, while the calls to RandomAccessForOrArray.read() (and it's Mapped IO derivatives) and PRTokeniser.nextToken() consume 17% combined. It's probably best to focus on those. Mike Marchywka-2 wrote: So you are doing everything internally with 32 bit chars? Not a big deal but if these are mostly zero there may be better ways to represent and save memory. You may say, well RAM is cheap but that doesn't matter since low level caches are fixed but I guess you can get a bigger disk and say VM is unlimited. are actually consuming run time, and this method isn't one of them (no matter how much it could be optimized). The only person with data claimed otherwise :) tp://1t3xt.info/tutorials/keywords/ -- View this message in context: http://old.nabble.com/performance-follow-up-tp28322800p28344478.html Sent from the iText - General mailing list archive at Nabble.com. -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello trumpetinc, On Apr 23, 2010, at 7:29 PM, trumpetinc wrote: Giovanni - if your source PDFs are small enough, you might want to try this, just to get a feel for the impact that IO blocking is having on your results (read entire PDF into byte[] and use PdfReader(byte[])) Trying it right now ... The StringBuffer could definitely be replaced with a StringBuilder, and it could be re-used instead of re-allocating for each call to nextTokeen() This is what I applied yesterday with the patch I posted. It includes both changes in PRTokeniser: StringBuilder + reusing the same instances ... the improvement is somewhere around 6.2% faster for my test case. I want to try this one you suggest above ... and then I will post the new numbers plus the cumulative patch I have ... Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Parsing PDF requires a lot of random access. It tends to be chunked - move to a particular offset in the file, then parse as a stream (this is why paging makes sense, and why memory mapping is effective until the file gets too big). But the parsing is incredibly complex. You can have nested object structures, lots of alternative representations for the same type of data, etc... And we definitely don't know size of any of these structures ahead of time. hmmm - just had a thought on IO performance. I'll post that in a separate message so we can keep the technical discussion separate. - K Mike Marchywka-2 wrote: You can have alt implementations in the mean time if you know size a priori. Ideally you would like to be able to operate on a stream and scrap random access. -- View this message in context: http://old.nabble.com/performance-follow-up-tp28322800p28345099.html Sent from the iText - General mailing list archive at Nabble.com. -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
One thing occurs to me on the IO performance... If we are using a memory mapped file, the backing buffer is, by definition, on the native side of the virtual/native boundary. So readying one byte at a time requires a lot of round trip across that boundary. Even with memory mapping, it may make sense to do some sort of paging... I'll have to think on that a bit. - K Giovanni Azua-2 wrote: Hello trumpetinc, On Apr 23, 2010, at 7:29 PM, trumpetinc wrote: Giovanni - if your source PDFs are small enough, you might want to try this, just to get a feel for the impact that IO blocking is having on your results (read entire PDF into byte[] and use PdfReader(byte[])) Trying it right now ... The StringBuffer could definitely be replaced with a StringBuilder, and it could be re-used instead of re-allocating for each call to nextTokeen() This is what I applied yesterday with the patch I posted. It includes both changes in PRTokeniser: StringBuilder + reusing the same instances ... the improvement is somewhere around 6.2% faster for my test case. I want to try this one you suggest above ... and then I will post the new numbers plus the cumulative patch I have ... Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/ -- View this message in context: http://old.nabble.com/performance-follow-up-tp28322800p28345102.html Sent from the iText - General mailing list archive at Nabble.com. -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Date: Fri, 23 Apr 2010 11:53:09 -0700 From: forum_...@trumpetinc.com To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up Parsing PDF requires a lot of random access. It tends to be chunked - move to a particular offset in the file, then parse as a stream (this is why paging makes sense, and why memory mapping is effective until the file gets Yes, that is great but instead of a generic MRU approach are there better predictions you can make, even start loaing pages before having to wait later etc? Maybe multithreading makes sense here. too big). But the parsing is incredibly complex. You can have nested object structures, lots of alternative representations for the same type of data, etc... surely there are rules and I'm sure this topic has been beaten to death in many CS courses ( as have stats LOL). Profiling should point to some suspects. Algorithmic optimizations may be possible as maybe just coding changes. Most compilers operate sequentially on input in maybe multiple passes I'm sure you can find ideas easily in a vraiety of sources. And we definitely don't know size of any of these structures ahead of time. well, you don;t need to know if a week ahead of time, but you could maybe waste an access or two finding sizes if that can be done more quickly than just reading everything. _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello trumpetinc,
On Apr 23, 2010, at 10:50 PM, trumpetinc wrote:
Don't know if it'll make any difference, but the way you are reading the file
is horribly inefficient. If the code you wrote is part of your test times,
you might want to re-try, but using this instead (I'm just tossing this
together - there might be type-os):
No, pre-loading the PDF template with the IO code I submitted was not part of
the performance tests before. I added it quick and dirty just to try out and
saw the massive performance improvement, I should have been skeptical but the
Latin spirit took over :)
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buf = new byte[8092];
int n;
while ((n = is.read(buf)) = 0) {
baos.write(buf, 0, n);
}
return baos.toByteArray();
Thank you, I will try this one later ...
From your results, are you seeing a big difference between iText and the
competitor when you aren't flattening fields vs you are flattening fields?
Your profiling results aren't indicating bottlenecks in that area of the
code. If iText is much faster than the competitor in the non-flattening
scenario, but slower than the competitor in the flattening scenario, I'm
having a hard time reconciling the data presented so far.
HEADER is a PDF file with no fields
FOOTER is a PDF file with fields (needs to be populated and flattened i.e.
stamper.setFormFlattening(true))
I prepared the equivalent exact same code for iText and the alternative.
However, I did not measure the times for the two templates HEADER and FOOTER
separately. So I can not tell if iText is faster loading with flat PDF than the
alternative or if iText is faster loading the PDF with fields compared to the
alternative.
Just now I discovered that if the loaded PDF form does not have fields iText
performs much faster. So I just modified my test-case to disable the HEADER and
run and profile only FOOTER (the expensive one with fields) four times so that
the top bottlenecks for this case will be better evidenced.
Best regards,
Giovanni
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
I'd love to discuss specific ideas on prediction - are you familiar enough with the PDF spec to provide any suggestions? Some obvious ones are the xref table - but iText reads that entirely into memory one time and holds onto it, so it seems unlikely that pre-fetch would do much there (other than having the last 1MB of the file be the first block pre-fetched - but any sort of paging implementation would handle that already). The rest... well, from my experience with this, you've got objects that refer to other objects that refer to other objects. And there's really no way to know where in the object graph you need to go until you parse and then go there. So I think I'll need some concrete examples of how this might be done with PDF structure - just to get my creativity going! - K Mike Marchywka-2 wrote: Parsing PDF requires a lot of random access. It tends to be chunked - move to a particular offset in the file, then parse as a stream (this is why paging makes sense, and why memory mapping is effective until the file gets Yes, that is great but instead of a generic MRU approach are there better predictions you can make, even start loaing pages before having to wait later etc? Maybe multithreading makes sense here. too big). But the parsing is incredibly complex. You can have nested object structures, lots of alternative representations for the same type of data, etc... surely there are rules and I'm sure this topic has been beaten to death in many CS courses ( as have stats LOL). Profiling should point to some suspects. Algorithmic optimizations may be possible as maybe just coding changes. Most compilers operate sequentially on input in maybe multiple passes I'm sure you can find ideas easily in a vraiety of sources. And we definitely don't know size of any of these structures ahead of time. well, you don;t need to know if a week ahead of time, but you could maybe waste an access or two finding sizes if that can be done more quickly than just reading everything. _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/ -- View this message in context: http://old.nabble.com/performance-follow-up-tp28322800p28346601.html Sent from the iText - General mailing list archive at Nabble.com. -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Date: Fri, 23 Apr 2010 14:53:57 -0700 From: forum_...@trumpetinc.com To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up I'd love to discuss specific ideas on prediction - are you familiar enough with the PDF spec to provide any suggestions? No, I started to play with itext for some specific things and then lost time/interest/need but I have a general interest in the topic and may jump back in at some point. Some obvious ones are the xref table - but iText reads that entirely into memory one time and holds onto it, so it seems unlikely that pre-fetch would do much there (other than having the last 1MB of the file be the first block pre-fetched - but any sort of paging implementation would handle that already). The rest... well, from my experience with this, you've got objects that refer to other objects that refer to other objects. And there's really no way to know where in the object graph you need to go until you parse and then go there. So I think I'll need some concrete examples of how this might be done with PDF structure - just to get my creativity going! Well, in a case like that you may want to try to reorder and glean all the stuff you need from what you have in memory before following all the references. Along the lines of find both delims in your array and use String(byte[],offset,length) instead of append(char) a zillion times, scan your current local objects for references they need and que those up before chasing after each one. It may turn out that sorting these and getting them in some order creates a net time savings- I wouldn't have believed this myself until I actually sorted a huge dataset prior to running a program and it turned it from impractical to practical runtime due to increased access coherence. Disk is slower than the low level cache :) _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Thank you. I'll include your changes.
Paulo
From: Giovanni Azua [brave...@gmail.com]
Sent: Thursday, April 22, 2010 1:02 AM
To: itext-questions@lists.sourceforge.net
Subject: [iText-questions] performance follow up
Hello,
Good news ... after applying the attached patch to trunk and doing yet another
performance experiment using the previously posted workload these are the
results:
BEFORE (trunk)
MeanVariance
15.125 5.514
15.440 3.474
15.258 9.736
15.621 23.869
15.449 4.817
15.500 2.662
15.221 8.431
15.319 3.419
15.142 1.626
15.457 3.972
AFTER (trunk + patch)
MeanVariance
14.404 5.928
14.487 16.781
14.132 1.618
14.314 3.174
14.663 7.522
14.542 15.086
14.283 6.924
14.399 2.064
14.205 1.609
14.471 2.761
The mean values look surprisingly much better than in the office. I'm running
here Snow Leopard with JVM 1.6.0_19.
Is iText with the patch better than before?
The paired observation of the means are:
{(15.125, 14.404),
(15.440, 14.487),
(15.258, 14.132),
(15.621, 14.314),
(15.449, 14.663),
(15.500, 14.542),
(15.221, 14.283),
(15.319, 14.399),
(15.142, 14.205),
(15.457, 14.471)}
The performance differences constitute a sample of 10 observations:
{0.721, 0.953, 1.126, 1.307, 0.786, 0.958, 0.938, 0.92, 0.937, 0.986}
For this sample:
Sample mean = 0.9632
Sample variance = 0.02651
Sample standard Deviation = 0.16282
Confidence interval for the mean = 0.9632 +/- t*sqrt(0.02651/10) = 0.9632 +/-
t*0.0514
The 0.95 quantile of a t-variate with df=N-1=10-1=9 is 1.833113
= 95% confidence interval = 0.9632 +/- 1.833113*0.0514 =
[0.9632-0.09422,0.9632+0.09422] = [0.86898,1.05742]
Since the confidence interval does NOT include zero we can conclude that the
performance improvement is significative (patch is better than no patch) and
will be approximately of (0.9632/15.3532)*100% = 6.2%
I also ran the workload connected to the profiler and the number of
StringBuffer instances decreased to 846'988
The Letter PDF looks good i.e. the patch didn't seem to break anything but you
will have to run the unit tests on it.
Best regards,
Giovanni
PS: There are still some StringBuffer around to fix ...
Aviso Legal:
Esta mensagem é destinada exclusivamente ao destinatário. Pode conter
informação confidencial ou legalmente protegida. A incorrecta transmissão desta
mensagem não significa a perca de confidencialidade. Se esta mensagem for
recebida por engano, por favor envie-a de volta para o remetente e apague-a do
seu sistema de imediato. É proibido a qualquer pessoa que não o destinatário de
usar, revelar ou distribuir qualquer parte desta mensagem.
Disclaimer:
This message is destined exclusively to the intended receiver. It may contain
confidential or legally protected information. The incorrect transmission of
this message does not mean the loss of its confidentiality. If this message is
received by mistake, please send it back to the sender and delete it from your
system immediately. It is forbidden to any person who is not the intended
receiver to use, distribute or copy any part of this message.
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Cool, analysis is always a plus and easier to discuss than adjectives. Just a few rather trivial comments. Date: Thu, 22 Apr 2010 02:02:31 +0200 From: To: itext-questions@lists.sourceforge.net Subject: [iText-questions] performance follow up Hello, Good news ... after applying the attached patch to trunk and doing yet another performance experiment using the previously posted workload these are the results: [...] Is iText with the patch better than before? This of course is where you consult Mark Twain. LOL. iText is or isn't better than before ( for some particular use case) irrespective of the data you currently have but the question is does the data allow you to reject the conclusion that they are have the same execution times with some confidence level? Finding ways to explain or attribute the noise into somekind of model of course would be a reasonable thing to consider if you had a few more test cases with some relevant parameters( number of fonts you will need or something). The statistics are just a guide to help you infer something causal- in this case perhaps something like, did the patch cause itext to get better? as you suggested originally. If you can start describing where and how much it got better, response surfaces I guess, then of course you are starting to develop strategy logic, and could take a given task and feed it to the patched or non patched version ( among a new family of altnerative implementations) depending on the parameters you know about it- obviously for the cases you have only one decision makes sense andd off hand based on what you said about nature of patch I don't know of any case where generating gratuitous garbage is a good strategy LOL. The paired observation of the means are: At this stage it is usually helpful to look at the data, not just start dumping it into equations you found in a book. I'm not slamming you at all, just that its helpful to have a check on your analysis even if you are using something canned like Ror a commercial package, more so if you just wrote the analysis stuff today. Don't ignore things like histograms etc, after all my criticisms of PDF for its ability to obscure information with art, sometimes there are pictures worth a thousand words. And of course using the pictures to suggest various sanity checks you can write. The Letter PDF looks good i.e. the patch didn't seem to break anything but you will have to run the unit tests on it. LOL, often people forget this step. Also it sounds like the alt pacakage is still faster by a clinically significant amount- an amount relevant to someone. There may be more coding optimiztions or algorithmic optimizations. for example, converting a string to a byte array could have some benefits, hard to know off hand since that may incur more java code then native code to manipulate but something to consider in a more general case. With a byte array you may be able to avoid creating lots of temp string, just make an int table of the locations of new tokens or pass around indexes instead of temp token strings. etc etc _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Paulo Soares wrote: Thank you. I'll include your changes. Due to the lack of time, I wasn't able to follow the discussion, but I've just read the latest mails, and I also want to thank you for the performance tests and improvements. -- This answer is provided by 1T3XT BVBA http://www.1t3xt.com/ - http://www.1t3xt.info -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello, On Apr 22, 2010, at 6:49 PM, 1T3XT info wrote: Paulo Soares wrote: Thank you. I'll include your changes. Due to the lack of time, I wasn't able to follow the discussion, but I've just read the latest mails, and I also want to thank you for the performance tests and improvements. No problem! I am happy to help .. it is a win-win :) The currently established commercial PDF solution I was comparing iText against is fast yes and with a lot of imagination and some compromises somehow you manage to achieve the use-case that you need but the design shortcomings and bugs it has are countless plus the huge risks because of their close code. But this is of course my personal opinion, and not the bank policy :) I might propose some more patches, it would be great to get the performance numbers at least as good as the commercial solution ... 23.8% response time difference still to go. Would this list be the right place for proposing new patches or is there a dedicated list for development? Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Post in this list, that way it won't be lost. Paulo - Original Message - From: Giovanni Azua To: Post all your questions about iText here Sent: Thursday, April 22, 2010 8:38 PM Subject: Re: [iText-questions] performance follow up Hello, On Apr 22, 2010, at 6:49 PM, 1T3XT info wrote: Paulo Soares wrote: Thank you. I'll include your changes. Due to the lack of time, I wasn't able to follow the discussion, but I've just read the latest mails, and I also want to thank you for the performance tests and improvements. No problem! I am happy to help .. it is a win-win :) The currently established commercial PDF solution I was comparing iText against is fast yes and with a lot of imagination and some compromises somehow you manage to achieve the use-case that you need but the design shortcomings and bugs it has are countless plus the huge risks because of their close code. But this is of course my personal opinion, and not the bank policy :) I might propose some more patches, it would be great to get the performance numbers at least as good as the commercial solution ... 23.8% response time difference still to go. Would this list be the right place for proposing new patches or is there a dedicated list for development? Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/-- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello Mike,
On Apr 22, 2010, at 12:22 PM, Mike Marchywka wrote:
This of course is where you consult Mark Twain. LOL.
iText is or isn't better than before ( for some particular
use case) irrespective of the data you currently have
but the question is does the data allow
you to reject the conclusion that they are have the same
execution times with some confidence level?
Good, this is exactly what I meant :)
Finding ways to explain or attribute the noise into some kind
of model of course would be a reasonable thing to
consider if you had a few more test cases with some
relevant parameters( number of fonts you will need or something).
The performance comparison is based on the representative test case exactly as
business wants it.
As far as I know we need only two fonts: light and bold. So the number of fonts
is not a parameter.
the parameters you know about it- obviously for the cases
you have only one decision makes sense andd off hand based
on what you said about nature of patch I don't know of any
case where generating gratuitous garbage is a good strategy LOL.
I know ... but hypothetically my patch could have well fixed the generating
gratuitous garbage while the use-case still be slow i.e. my point being to make
sure and prove that the patch delivers the promised performance gain.
The paired observation of the means are:
At this stage it is usually helpful to look at the data, not
just start dumping it into equations you found in a book.
This book is the official reference for the course in Advance System
Performance Analysis I am taking for my graduate CS Master program in the
top-10 Technology University of the world ... so no, it is not just equations I
found in a book :)
If you need to compare the performance of two systems and you have paired
observations, this is the recipe you want to use.
I'm not slamming you at all, just that its helpful
to have a check on your analysis even if you
No worries, I am actually very happy with your feedback. I would actually like
to thank you for your insights.
Also it sounds like the alt pacakage is still faster by
a clinically significant amount- an amount relevant to someone.
Now only 23.8% to go. We only need to make 4 more fixes like the last one and
the gap will be gone :) The Profiler shows there are still several bottlenecks
topping which could also be easy fixes e.g. PRTokeniser.isWhitespace is a
simple boolean condition that just happen to be called gazillion times e.g.
35'622'000 times for my test workload ... if instead of doing it like:
public static final boolean isWhitespace(int ch) {
return (ch == 0 || ch == 9 || ch == 10 || ch == 12 || ch == 13 || ch == 32);
}
we used a bitwise binary operator with the appropriate mask(s), there could be
some good performance gain ...
Best regards,
Giovanni--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
I like your approach! A simple if (ch 32) return false; at the very top
would give the most bang for the least effort (if you do go the bitmask
route, be sure to include unit tests!).
I know there were a lot of calls to this method, but I'm curious: in your
pofiling, how much of the total processing _time_ was spent in that routine?
The if() would make this 6 times faster, but it's hard to believe that this
call has any appreciable contribution to runtime.
Keep it up!
- K
Giovanni Azua-2 wrote:
Now only 23.8% to go. We only need to make 4 more fixes like the last one
and the gap will be gone :) The Profiler shows there are still several
bottlenecks topping which could also be easy fixes e.g.
PRTokeniser.isWhitespace is a simple boolean condition that just happen to
be called gazillion times e.g. 35'622'000 times for my test workload ...
if instead of doing it like:
public static final boolean isWhitespace(int ch) {
return (ch == 0 || ch == 9 || ch == 10 || ch == 12 || ch == 13 || ch
== 32);
}
we used a bitwise binary operator with the appropriate mask(s), there
could be some good performance gain ...
Best regards,
Giovanni
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list:
http://1t3xt.info/tutorials/keywords/
--
View this message in context:
http://old.nabble.com/performance-follow-up-tp28322800p28334733.html
Sent from the iText - General mailing list archive at Nabble.com.
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello,
On Apr 22, 2010, at 10:59 PM, Giovanni Azua wrote:
PRTokeniser.isWhitespace is a simple boolean condition that just happen to be
called gazillion times e.g. 35'622'000 times for my test workload ... if
instead of doing it like:
public static final boolean isWhitespace(int ch) {
return (ch == 0 || ch == 9 || ch == 10 || ch == 12 || ch == 13 || ch ==
32);
}
we used a bitwise binary operator with the appropriate mask(s), there could
be some good performance gain ...
The function already exists in
http://java.sun.com/javase/6/docs/api/java/lang/Character.html#isWhitespace%28char%29
I checked and it already uses bitwise binary operators with the right masks
... we would only need to inline it to avoid the function call costs.
Best regards,
Giovanni--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
The semantics are different (the JSE call includes more characters in it's
definition of whitespace than the PDF spec). Not saying that it can't be
easily done, but throwing an if statement at it and seeing what impact it
has on performance is pretty easy also.
What was the overall time %age spent in this call in your tests?
Giovanni Azua-2 wrote:
Hello,
On Apr 22, 2010, at 10:59 PM, Giovanni Azua wrote:
PRTokeniser.isWhitespace is a simple boolean condition that just happen
to be called gazillion times e.g. 35'622'000 times for my test workload
... if instead of doing it like:
public static final boolean isWhitespace(int ch) {
return (ch == 0 || ch == 9 || ch == 10 || ch == 12 || ch == 13 || ch
== 32);
}
we used a bitwise binary operator with the appropriate mask(s), there
could be some good performance gain ...
The function already exists in
http://java.sun.com/javase/6/docs/api/java/lang/Character.html#isWhitespace%28char%29
I checked and it already uses bitwise binary operators with the right
masks ... we would only need to inline it to avoid the function call
costs.
Best regards,
Giovanni
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list:
http://1t3xt.info/tutorials/keywords/
--
View this message in context:
http://old.nabble.com/performance-follow-up-tp28322800p28334828.html
Sent from the iText - General mailing list archive at Nabble.com.
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
From: brave...@gmail.com
Date: Thu, 22 Apr 2010 23:22:36 +0200
To: brave...@gmail.com
CC: itext-questions@lists.sourceforge.net
Subject: Re: [iText-questions] performance follow up
Hello,
On Apr 22, 2010, at 10:59 PM, Giovanni Azua wrote:
PRTokeniser.isWhitespace is a simple boolean condition that just happen to be
called gazillion times e.g. 35'622'000 times for my test workload ... if
instead of doing it like:
public static final boolean isWhitespace(int ch) {
return (ch == 0 || ch == 9 || ch == 10 || ch == 12 || ch == 13 || ch == 32);
}
does this have to be int vs char or byte? I think earlier I suggested
operating on byte[] instead of making a bunch of temp strings
but I don't know the context well enough to know if this makes sense.
Certainly demorgan can help but casts and calls are not free either.
Also, maybe hotspot runtime has gotten better but I have found in
the past that look up tables can quickly become competititve
with bit operators ( if your param is byte instead of int, a
256 entry table can tell you if the byte is a member of which classes).
we used a bitwise binary operator with the appropriate mask(s), there could
be some good performance gain ...
The function already exists in
http://java.sun.com/javase/6/docs/api/java/lang/Character.html#isWhitespace%28char%29
I checked and it already uses bitwise binary operators with the right masks
... we would only need to inline it to avoid the function call costs.
Best regards,
Giovanni
_
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
FYI I already use a table to map the char to the result for the delimiter
testing and the speed improvement was zero in relation to plain comparisons.
Paulo
- Original Message -
From: trumpetinc
To: itext-questions@lists.sourceforge.net
Sent: Thursday, April 22, 2010 10:30 PM
Subject: Re: [iText-questions] performance follow up
The semantics are different (the JSE call includes more characters in it's
definition of whitespace than the PDF spec). Not saying that it can't be
easily done, but throwing an if statement at it and seeing what impact it
has on performance is pretty easy also.
What was the overall time %age spent in this call in your tests?
Giovanni Azua-2 wrote:
Hello,
On Apr 22, 2010, at 10:59 PM, Giovanni Azua wrote:
PRTokeniser.isWhitespace is a simple boolean condition that just happen
to be called gazillion times e.g. 35'622'000 times for my test workload
... if instead of doing it like:
public static final boolean isWhitespace(int ch) {
return (ch == 0 || ch == 9 || ch == 10 || ch == 12 || ch == 13 || ch
== 32);
}
we used a bitwise binary operator with the appropriate mask(s), there
could be some good performance gain ...
The function already exists in
http://java.sun.com/javase/6/docs/api/java/lang/Character.html#isWhitespace%28char%29
I checked and it already uses bitwise binary operators with the right
masks ... we would only need to inline it to avoid the function call
costs.
Best regards,
Giovanni
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list:
http://1t3xt.info/tutorials/keywords/
--
View this message in context:
http://old.nabble.com/performance-follow-up-tp28322800p28334828.html
Sent from the iText - General mailing list archive at Nabble.com.
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
Hello, On Apr 22, 2010, at 11:30 PM, trumpetinc wrote: The semantics are different (the JSE call includes more characters in it's definition of whitespace than the PDF spec). Not saying that it can't be easily done, but throwing an if statement at it and seeing what impact it has on performance is pretty easy also. I will try your suggestion too ... What was the overall time %age spent in this call in your tests? Total 10 seconds that accounts for 1% ... 1% is not much but how the Swiss people use to say who does not care about the cents, do not deserve the francs or something like that :) Best regards, Giovanni -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
Re: [iText-questions] performance follow up
From: Date: Thu, 22 Apr 2010 22:59:43 +0200 To: itext-questions@lists.sourceforge.net Subject: Re: [iText-questions] performance follow up Hello Mike, On Apr 22, 2010, at 12:22 PM, Mike Marchywka wrote: This of course is where you consult Mark Twain. LOL. iText is or isn't better than before ( for some particular use case) irrespective of the data you currently have but the question is does the data allow you to reject the conclusion that they are have the same execution times with some confidence level? Good, this is exactly what I meant :) Finding ways to explain or attribute the noise into some kind of model of course would be a reasonable thing to consider if you had a few more test cases with some relevant parameters( number of fonts you will need or something). The performance comparison is based on the representative test case exactly as business wants it. Yes, I know, I'm simply pointing out this is part of a bigger issue that may or may not be relevant to itext but in general is something to consider for long tasks. For example, maybe see FFTW. As far as I know we need only two fonts: light and bold. So the number of fonts is not a parameter. I made that up as a simple strawman. If you make a model for execution time given some parameters that are important, you can pick a specific implementation that you expect to be faster. Again a bit of an extrapolation to make your stats analysis more worthwhile. This book is the official reference for the course in Advance System Performance Analysis I am taking for my graduate CS Master program in the top-10 Technology University of the world ... so no, it is not just equations I found in a book :) LOL, you need to see Allen Greedspan interview, may have been on CNBC or 60 minutes talking about financial models essentially saying he didn't understand them but bright PhD's were doing it so it must be right. The punchline is appeal to authority or credentials when a factual argument is more ala point. This in fact is how Mark Twain gets to the front so quickly. Again, I'm not suggesting you did anything wrong or bad, I haven't actually checked numbers or given the specific test a lot of thought- 9 data points is usually not all that conclusive in any case and I guess that's my point. Presumably you could keep measuring each case with and without patch and slowly ( sqrt N) get better estimate of average execution times. Then, end up with 9 data points that are difference in execution time for each case with/without patch and asymptoticallty measure arbitrarily small differences. However, it may be more helpful to look at pictures like histograms or at least run various assumption checks. You may have non-normal distros and those shapes can tell you something about causes, not always but it helps to look before taking one result and running with it. Now only 23.8% to go. We only need to make 4 more fixes like the last one and the gap will be gone :) The Profiler shows there are still I wouldn't count on the other one being the final solution to pdf creation. Do you have symbols info or can you profile it at all? _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 -- ___ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
[iText-questions] performance follow up
Hello,
Good news ... after applying the attached patch to trunk and doing yet
another performance experiment using the previously posted workload these
are the results:
BEFORE (trunk)
MeanVariance
15.125 5.514
15.440 3.474
15.258 9.736
15.621 23.869
15.449 4.817
15.500 2.662
15.221 8.431
15.319 3.419
15.142 1.626
15.457 3.972
AFTER (trunk + patch)
MeanVariance
14.404 5.928
14.487 16.781
14.132 1.618
14.314 3.174
14.663 7.522
14.542 15.086
14.283 6.924
14.399 2.064
14.205 1.609
14.471 2.761
The mean values look surprisingly much better than in the office. I'm
running here Snow Leopard with JVM 1.6.0_19.
Is iText with the patch better than before?
The paired observation of the means are:
{(15.125, 14.404),
(15.440, 14.487),
(15.258, 14.132),
(15.621, 14.314),
(15.449, 14.663),
(15.500, 14.542),
(15.221, 14.283),
(15.319, 14.399),
(15.142, 14.205),
(15.457, 14.471)}
The performance differences constitute a sample of 10 observations:
{0.721, 0.953, 1.126, 1.307, 0.786, 0.958, 0.938, 0.92, 0.937, 0.986}
For this sample:
Sample mean = 0.9632
Sample variance = 0.02651
Sample standard Deviation = 0.16282
Confidence interval for the mean = 0.9632 +/- t*sqrt(0.02651/10) = 0.9632
+/- t*0.0514
The 0.95 quantile of a t-variate with df=N-1=10-1=9 is 1.833113
= 95% confidence interval = 0.9632 +/- 1.833113*0.0514 =
[0.9632-0.09422,0.9632+0.09422] = [0.86898,1.05742]
Since the confidence interval does NOT include zero we can conclude that the
performance improvement is significative (patch is better than no patch) and
will be approximately of (0.9632/15.3532)*100% = 6.2%
I also ran the workload connected to the profiler and the number of
StringBuffer instances decreased to 846'988
The Letter PDF looks good i.e. the patch didn't seem to break anything but
you will have to run the unit tests on it.
Best regards,
Giovanni
PS: There are still some StringBuffer around to fix ...
PRTokeniser.patch
Description: Binary data
--
___
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
