Hello William, Am 29.06.2015 um 20:48 schrieb William Bader: > Does slightly increasing or decreasing STR_STATIC_SIZE make a > difference? Maybe the compiler is aligning on a larger boundary than the > calculation assumes, or maybe a large static area increases cache misses > by not allowing adjacent small strings to fit in the same cache block.
Increasing STR_STATIC_SIZE so that the final object size goes from 32 to 48 did not change the basic behaviour for insertion of short and long C strings. The alignment of data within the GooString class should be considered by the size computation. (sizeof(GooString) changes as intended) The alignment of GooString itself does not change in between the variants. (__alignof__(GooString) stays at 8) Alignment does probably play some role as insertion is faster for heap-allocated than for stack-allocated GooString instances. But this as already true for the current code and does not change with the new memory layout. > Are there ways to reduce the use of dynamic strings like what I did in > .https://bugs.freedesktop.org/show_bug.cgi?id=89096 ? There are certainly such opportunities [1] [2], but I'd say the small string optimization is used exaclty so that users of the class get such optimizations almost without effort. And of course, one could optimize such places and improve the small string optimization at the same time. Of course, in this case, my primary aim is to prevent wasting 8 bytes of memory for each dynamically allocated small string. Even if this can be done without any speed improvement, it would be a win IMHO. Best regards, Adam. [1] For example, I found calls of GooString::clear immediately followed by GooString::insert which should probably be replaced by a single call to GooString::Set. [2] I also suspect that it might be benefical if GooString::format and GooString::formatv would return a value instead of a pointer since that would be prevent a lot of dynamic allocation of small strings in the first place. But this would imply changing all 115 or so call sites instead of a localized change within GooString... (It would also make sense IMHO as GooString already is a handle to a value instead of a value itself.)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
