[
https://issues.apache.org/jira/browse/PDFBOX-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630122#comment-14630122
]
John Hewson commented on PDFBOX-2882:
-------------------------------------
I have some concerns about the use of synronization in ScratchFile.
{code}
if (isClosed.compareAndSet(false, true))
{
synchronized (isClosed)
{
java.io.RandomAccessFile localRAF = raf;
if (localRAF != null)
{
raf = null;
synchronized ( localRAF )
{
localRAF.close();
}
}
{code}
In the above code, why nest synchronized? Both isClosed and raf are fields of
the current object and their values are never shared outside of ScratchField,
so these two locks are functionally equivalent.
Also, why the use of compareAndSet? close() is called vary rarely, why not
simply synchronize the entire method? You're already paying the full cost of
synchronize for every read and write in readPage and writePage. This ties-in
with my next thought...
> 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]
