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
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(); >>
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
> 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
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
> 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
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
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
> 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
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
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
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
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
> 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 > b
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 furthe
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
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
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
> 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=multiaccount&ocid=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
> 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=multicalendar&ocid=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
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
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
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
> 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/
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
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
> 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
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
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
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 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
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, 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
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
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 "R"or 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
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/
[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/