On Mon, 2003-12-01 at 02:45, Glen Mazza wrote:
> --- John Austin <[EMAIL PROTECTED]> wrote:
> > 
> > The property strings are given to the Property
> > object
> > constructor by some path beginning with a SAX
> > parser.
> > It is reasonable to assume that the SAX parser loses
> > refs to most of these strings and that the Property
> > implementation retains the only references to these 
> > String objects.
> > 
> > How big are String Objects ? 
> > At least 16 bytes plus storage for characters. 
> > 
> > What does this save us ? 
> > Probably only about 1,600,000 bytes for this file. 
> > CPU cost of creating strings is probably similar to 
> > cost of checking string table for a copy.
> > 
> 
> Just to clarify, the (additional?) "CPU cost" you
> mentioning above is *not* occurring for the present
> process, correct?  I think you're referring to the
> cost that would be added as a result of the changes
> you're recommending (because there now will be a
> string table search to avoid duplication).

Going back to the beginning of my involvement, I found this
issue because Property searches are the high-runner for CPU
in FOP. I don't want to split hairs in isolation over which
search/constructor sequence is faster. I want to remove the
conditions that cause the current pathology.

Hash table lookups are FAST. When we invest in object creation
we recover many times over in the end. 

> Also, the "string table" you mention--I think you're
> speaking generically, but is there a specific, already
> available construct in Java that we can use for this
> purpose in FOP?  I'd like to find out what you have in
> mind for a specific implementation.

HashMap works fine the way Peter has it set up in alt-design.

I use the same construct in the Perl code I use to analyze the
large sample FO files.

-- 
John Austin <[EMAIL PROTECTED]>

Reply via email to