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