Jeff Clites <[EMAIL PROTECTED]> wrote: > To handle multiple files, we'll probably need to generate a .c to hold > the C strings (instead of the .h), and have an extern declaration in > the .h (since it will be included in multiple files). That's assuming > they'll all be aggregated into a single file (which makes sense).
Well, there is one include file per .c (e.g. objects.str), which holds defines for this file. The global string table is included only in string.c to construct the strings. There is no need to have include files with any extern declarations or includes for multiple files. > Here is a related patch, to cause us to cache the hash values of all > strings (on demand). The important part is that the cached value is > cleared out in unmake_COW, which is called any time we might mutate the > string Yep. Should work. > side-effect of allowing c2str.pl to be slightly simpler, since it won't > need to pre-calculate the hash value (since const strings are the same > as any others, and their hash value will be calculated and cached if it > is ever needed). We still can precalculate for these constant strings and save some extra cylces (the precalculated value isn't used yet, but ...) And we can precalculate hash values for the string constants in the constant table during compilation (and write it into the PBC). > This change speeds up the attached benchmark by a factor of 1.86 in the > optimize case (via --optimize, so -Os), or 3.73 in the unoptimized case > (on Mac OS X): Wheee, that's a lot. I'll apply it RSN - I'm currently fighting with the Makefile (classes stuff moved to main) > JEff leo
