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]>