[
https://issues.apache.org/jira/browse/PDFBOX-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630123#comment-14630123
]
John Hewson commented on PDFBOX-2882:
-------------------------------------
Looking at the following code:
{code}
byte[] readPage(int pageIdx) throws IOException
{
checkClosed();
if ((pageIdx < 0) || (pageIdx >= pageCount))
{
throw new IOException("Page index out of range: " + pageIdx + ". Max
value: " + (pageCount - 1) );
}
if (pageIdx < inMemoryMaxPageCount)
{
return inMemoryPages[pageIdx];
}
// handle corner case when close is called by another thread
java.io.RandomAccessFile localRAF = raf;
checkClosed();
synchronized ( localRAF )
{
byte[] page = new byte[PAGE_SIZE];
localRAF.seek(((long)pageIdx - inMemoryMaxPageCount) * PAGE_SIZE);
localRAF.readFully(page);
return page;
}
}
{code}
This pattern of performing checks outside the synchronized block occurs in
several methods, but I don't see the benefit. These checks are likely to fail
only in very rare error conditions, why not simply synchronize the entire
method to reduce the complexity? (Also, why lock on RandomAccessFile when it
can be null? Why not lock on this or a deficated lock field? Or better yet, use
"synchronized" methods).
> Improve performance when using scratch file
> -------------------------------------------
>
> Key: PDFBOX-2882
> URL: https://issues.apache.org/jira/browse/PDFBOX-2882
> Project: PDFBox
> Issue Type: Improvement
> Components: Parsing
> Affects Versions: 2.0.0
> Reporter: Timo Boehme
> Assignee: Timo Boehme
> Priority: Minor
> Attachments: ScratchFile.java, ScratchFileBuffer.java
>
>
> The current scratch file implementation uses many direct I/O calls which
> slows down parsing compared with in-memory scratch buffer considerably.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
