> 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
>
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
On Fri, Apr 23, 2010 at 5:27 PM, Filipe Sousa wrote:
> Hi Paulo,
>
> I believe your fix (@4339) has created another bug. I'm attaching two
> pdf files: bad.pdf (from trunk) and good.pdf (from trunk without
> 4339). In my particular case, there is a problem between page 1 and
> page 2. With your p
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
> 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 - m
btw, why do these need to get changed to ints?
and, do you notice with task manager that
CPU is not at 100 pct? This often indicates
disk limit- either explicit IO or VM.
I've actually had c++ code that I thought
was computationally limited turn out to
be IO limited. Often simple compression
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 By
I am sooo sorry the performance is worse with the change for pre-loading the
PDFs in the test-case :(( the problem was that I ran the benchmarks with a
small mistake in my test case ...
Loading the HEADER demonstrates how to load flattened pre-formatted PDF part
templates ...
Loading the
I am sooo sorry the performance is worse with the change for pre-loading the
PDFs in the test-case :(( the problem was that I ran the benchmarks with a
small mistake in my test case ...
The HEADER tests how to load flattened PDF part templates ...
The FOOTER tests how to load PDF part te
FYI:
Listing 2.3: DirectorPhrases1.java
public static final Font BOLD_UNDERLINED = new Font(Font.TIMES_ROMAN,
12, Font.BOLD | Font.UNDERLINE);
...does not compile
Jason
***This is a transmission from Purdue Employees Federal Credit
Union (PEFCU) and is intended solely for its authorized
reci
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
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
obj
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 rig
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
conver
> 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
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
> 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 tha
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
>
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
iText can merge any type of PDFs and maintain the content, including SWFs.
-Original Message-
From: martin.st...@omya.com [mailto:martin.st...@omya.com]
Sent: Friday, April 23, 2010 10:37 AM
To: itext-questions@lists.sourceforge.net
Subject: [iText-questions] Merge PDFs containing swf
H
Hello iText community
I want to merge a PDF containing a swf with another PDF (containing a swf
or not)
This does not seem to be supported well by PDF tools.
In the mailing list i only found how to embed a swf in a PDF and how to
extract it (what ends in the result that I am able to merge them)
On Thu, Apr 22, 2010 at 3:45 PM, David Hoffer wrote:
> Hi Michael,
>
> I feel your pain, I am in similar situation. The commercial side of
> the licensing is geared for very big projects only, nothing small. I
> had no choice but to use 2.x and FOP will be next if I need more.
> Again I don't n
> 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!
> 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
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 o
Hi Campus,
as far as I can see, there are different licenses depending on the type of
application. For desktop installations (when itext is shipped with an
application) for the first 250 desktop installations you have to pay 3000 $
and it goes up to 25 000 $ for 5 000 to 50 000 copies. So it gets c
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 check
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 conclusiv
Hi,
Thanks. I will not look at this again before some time next week.
I had a look at the methods you mentioned, and this stuff looks a lot more
complicated than I thought. I could not quite make the connection
from ColumnText to PdfLine. Anyway, I try again next week.
Have a nice weekend!
Pet
29 matches
Mail list logo
