Hello Mike,
On Apr 22, 2010, at 12:22 PM, Mike Marchywka wrote:
> This of course is where you consult Mark Twain. LOL.
> iText is or isn't "better than before" ( for some particular
> use case) irrespective of the data you currently have
> but the question is "does the data allow
> you to reject the conclusion that they are have the same
> execution times with some confidence level?"
>
Good, this is exactly what I meant :)
> Finding ways to explain or attribute the noise into some kind
> of model of course would be a reasonable thing to
> consider if you had a few more test cases with some
> relevant parameters( number of fonts you will need or something).
>
The performance comparison is based on the representative test case exactly as
business wants it.
As far as I know we need only two fonts: light and bold. So the number of fonts
is not a parameter.
> the parameters you know about it- obviously for the cases
> you have only one decision makes sense andd off hand based
> on what you said about nature of patch I don't know of any
> case where generating gratuitous garbage is a good strategy LOL.
>
I know ... but hypothetically my patch could have well fixed the generating
gratuitous garbage while the use-case still be slow i.e. my point being to make
sure and prove that the patch delivers the promised performance gain.
>> The paired observation of the means are:
> At this stage it is usually helpful to look at the data, not
> just start dumping it into equations you found in a book.
>
This book is the official reference for the course in Advance System
Performance Analysis I am taking for my graduate CS Master program in the
top-10 Technology University of the world ... so no, it is not just equations I
found in a book :)
If you need to compare the performance of two systems and you have paired
observations, this is the recipe you want to use.
> I'm not slamming you at all, just that its helpful
> to have a check on your analysis even if you
>
No worries, I am actually very happy with your feedback. I would actually like
to thank you for your insights.
> Also it sounds like the alt pacakage is still faster by
> a clinically significant amount- an amount relevant to someone.
>
Now only 23.8% to go. We only need to make 4 more fixes like the last one and
the gap will be gone :) The Profiler shows there are still several bottlenecks
topping which could also be easy fixes e.g. PRTokeniser.isWhitespace is a
simple boolean condition that just happen to be called gazillion times e.g.
35'622'000 times for my test workload ... if instead of doing it like:
public static final boolean isWhitespace(int ch) {
return (ch == 0 || ch == 9 || ch == 10 || ch == 12 || ch == 13 || ch == 32);
}
we used a bitwise binary operator with the appropriate mask(s), there could be
some good performance gain ...
Best regards,
Giovanni------------------------------------------------------------------------------
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
