On Thursday 19 June 2008 12:01:47 Will Coleda wrote: > On Thu, Jun 19, 2008 at 2:58 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > I'd like to replace all of the string_from_literal with const_string. > > While the former calculates the string length at compile time (and saves > > a very short strlen call at runtime), const_string uses a cache of > > constant string headers, trading a lookup cost to retrieve or store a > > singletone string header for not allocating a new non-constant string > > header on each invocation. > > We'll already have "Mutable" and "attributes" in the cache, so this is > > effectively a free optimization. > Does this cache work with dynops, dynpmcs, etc?? CONST_STRING (in core) is the compile-time cache, so it's indexed access into the constant string array. Because dynops and dynpmc's can't use that cache (they can't put indexes into libparrot, for obvious reasons), I recently added a keyed cache and made sure that all CONST_STRINGs compiled into libparrot are available that way too. If you use const_string in dynops and dynpmcs, they can use that keyed cache. It's a little bit slower than the indexed cache in core, but memoized strings that you aren't going to modify in place are very good. (Though dynpmcs can use the CONST_STRING macro, it's just a #define for const_string I added so that people can read core PMCs and use the same names for things as they would in dynpmcs without having to understand the differences between them. If you want a constant string that you aren't going to modify, use CONST_STRING. We should probably add a similar #define when we generate dynops.) -- c
