[jira] [Commented] (FOP-2190) decrease PDF file size when CS are enabled

2015-05-18 Thread Andreas L. Delmelle (JIRA)

[ 
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)


[jira] [Commented] (FOP-2190) decrease PDF file size when CS are enabled

2013-01-22 Thread Luis Bernardo (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559507#comment-13559507
 ] 

Luis Bernardo commented on FOP-2190:


in my tests performance was greatly improved by this change. I did not measure 
though how memory allocation was impacted.

the test was the following:
- use a long text document (around 100 pages) with the Arial font
- generate the PDF using the servlet that ships with FOP, making sure it uses a 
proper configured fop.xconf (i.e., uses the Arial font and does not disable CS)
- use ab (apache benchmark) to make 100 requests and look at the time 
measurements (after allowing for warm up)

note that I also added some time measurements inside the servlet to confirm the 
improvement in performance was not due to reduced HTTP transfer times (i.e., 
was really in the generation of the document)

it is possible that some different tests show other results.
 

> 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: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (FOP-2190) decrease PDF file size when CS are enabled

2013-01-21 Thread Glenn Adams (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559323#comment-13559323
 ] 

Glenn Adams commented on FOP-2190:
--

i've implemented a portion of this patch already in FOP-2195, however I am not 
prepared to apply the code that switches between the DX/DP text drawing 
functions since it imposes a significant performance and memory allocation 
penalty in order to reduce PDF output size; in particular, the use of 
String.substring() will cause a great amount of additional String allocation 
that would not otherwise be present; in order to apply this additional 
optimization, I think we need to:

(1) create a PDF renderer configuration option that allows the user to express 
whether to optimize PDF size or processing speed;
(2) rewrite the proposed changes to not require additional string allocation;

> 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: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira