Yes, now we have the same performance as the old may-version, it will be ok.
However, better parsing/render-performance would always be fine.
thanks and regarts, Manfred
Am 15.07.2015 um 15:43 schrieb Timo Boehme:
The latest ScratchFile* versions attached to PDFBOX-2882 fix the
described excep
The latest ScratchFile* versions attached to PDFBOX-2882 fix the
described exception and improve on ScratchFileBuffer.clear() command.
Regarding speed test of file provided by Manfred Pock: on my machine
rendering is nearly the same for only scratch file usage vs. using
ScratchFile with allowe
I also wouldn't expect an improvement with 256k bytes of in-memory
pages. You should add possibly an 1000 times larger value - or what you
would like to use.
I will later have a look into the reason for your exception.
Timo
Am 15.07.2015 um 12:57 schrieb Manfred Pock:
Hi Timo,
i have seen
Hi Timo,
i have seen and tried it again. I have set maxInMemoryByteSize to 256000
and i cannot see a real improvement.
But i got an Exception with the appended pdf.
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at
org.apache.pdfbox.contentstream.PDFStreamEngine.sh
Hi Manfred,
there is another update of ScratchFile. It now is able to use a certain
amount of main memory before using the scratch file. Could you give it a
try? You will have to change the source a bit since the constructor
getting the allowed amount of memory is currently not supported by
P
Hi Timo,
i have test it with different pdf's and die performance ist nearly of
the version from may. Just a little bit slower.
It will be ok, but it will be nice if it will performe better ;-)
thanks and regarts.
Manfred
Am 15.07.2015 um 10:24 schrieb Timo Boehme:
Hi Manfred,
the issue sho
Hi Manfred,
the issue should be fixed in the updated versions attached to
PDFBOX-2882. Please give them a try.
Timo
Am 15.07.2015 um 09:51 schrieb Manfred Pock:
Hi Timo,
i have tried it put it doesn't work now and i get different exceptions
or Errors
i looks like that there is a problem
Hi Manfred,
yes, I also encountered an error while testing another file now. I will
check the implementation.
Best,
Timo
Am 15.07.2015 um 09:51 schrieb Manfred Pock:
Hi Timo,
i have tried it put it doesn't work now and i get different exceptions
or Errors
i looks like that there is a prob
Hi Timo,
i have tried it put it doesn't work now and i get different exceptions
or Errors
i looks like that there is a problem with any kind of images, the rest
will be shown.
for example:
SCHWERWIEGEND: TIFFFaxDecoder: Invalid code encountered while decoding
2D group 4 compressed data.
j
I've created PDFBOX-2882 with a drop-in replacement of the scratch file
implementation.
@Manfred: Could you please test if this helps in your scenario to
increase performance?
Best,
Timo
Am 14.07.2015 um 13:47 schrieb Timo Boehme:
Hi,
instead of having a linked page list in ScratchFileBuffe
Hi,
instead of having a linked page list in ScratchFileBuffer I would
propose having a list of pages with the page numbers (integer) kept in
memory (takes 1k for 1MB data). This would ease page handling, seeking
does not need I/O-operations and caching of pages would be a lot easier.
I may fi
Hi,
as I see it (had only a quick look at the implementation) the
ScratchFileBuffer implementation is not optimal for fast random access.
Single writes of bytes are not buffered but directly written to the file
- a lot of I/O-operations) and seek operations have to travel the linked
page list
> Manfred Pock hat am 14. Juli 2015 um 12:15
> geschrieben:
>
>
> Yes, the input is a inputstream. I can try it direct from file.
>
> But in general we get the pdf from an document management system as stream.
> Does make sense that i save the pdf to file before?
If possible, yes. As I already
Yes, the input is a inputstream. I can try it direct from file.
But in general we get the pdf from an document management system as stream.
Does make sense that i save the pdf to file before?
Why is there so an big performance difference beetween the version from
May and the current version, if
Hi,
> Manfred Pock hat am 14. Juli 2015 um 11:39
> geschrieben:
>
>
> Ok, we load the pdf with useScratchFiles = true, if we load them with
> false the performance is better, but a little bit slower than the old one.
What do you use as input, a stream or a real file? If the latter you should u
Ok, we load the pdf with useScratchFiles = true, if we load them with
false the performance is better, but a little bit slower than the old one.
But now it need more memory. I cannot load some pdfs with the current
version with the same java-memory configuration.
Am 14.07.2015 um 11:26 schrie
Hi,
we use the Pdfbox-trunkversion to render pdf's, currently we use the
version from 12. May 2015.
Today i have done an update to the current version and have test it. It
seems to be that it need now much more time to render pdf's, it depends
of the size of the pdf.
for example you can tr
17 matches
Mail list logo
