[
https://issues.apache.org/jira/browse/FOP-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549109#comment-14549109
]
Andreas L. Delmelle commented on FOP-2190:
------------------------------------------
Reading the comment about String.substring potentially causing a "significant
performance and memory allocation penalty" actually made me chuckle slightly...
Do we have any measurements/numbers in that regard? How many calls to
substring() are we talking about? How long, on average, is the base string? How
long are the substrings, typically?
I am not at all convinced this is an issue to be worried about, since:
1° In older Java versions (pre 1.7r6), String.substring() runs in constant time
and just returns a new instance wrapped around the same char array as the
original, taking up the space of a reference and two ints only for the duration
of the call (see also 2°)
2° Even in more recent Java versions, those newly allocated String instances,
with their own char arrays, have a very short lifespan (= just the duration of
the drawTextD* executions), so any allocated memory for the new char array can
be reclaimed as soon as the method is exited. Because of that short lifespan,
the instances and arrays in question will likely never even leave the stack.
The only scenario where the newer implementation (= a completely independent
String instance) would have a "significant" impact on performance and memory
would be the case where one repeatedly takes rather large substring from
another very large string.
In most common use cases on modern systems, however, the difference will be
unnoticeable, and performance may even benefit, as Luis' measurements seem to
demonstrate (although I cannot immediately explain why that would be --Strings
are immutable, so no need to synchronize any mutations...?)
> decrease PDF file size when CS are enabled
> -------------------------------------------
>
> Key: FOP-2190
> URL: https://issues.apache.org/jira/browse/FOP-2190
> Project: Fop
> Issue Type: Improvement
> Components: renderer/pdf
> Affects Versions: 1.1, trunk
> Reporter: Luis Bernardo
> Attachments: fop-2190.patch
>
>
> when CS are enabled, the current code may make use of the operators Td and Tj
> in situations where TJ would be appropriate leading to an increase in file
> size. note: this happens in the PDFPainter.drawText().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
