Benjamin Goldberg <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> >> We currently have constant Key and Sub PMCs both created from the >> packfile at load time. They live in the constant_table pointing to a >> constant PMC pool. But we need more. >> >> We have allover the core code like this: >> >> string_from_cstring(interpreter, "pIt", 0)
> Don't do that. Instead, do: > string_from_cstring(interpreter, "pIt", PObj_external_FLAG); > This will allow parrot to avoid making a copy of "pIt". Yep, that's right. And such constant strings should be contructed with the terminating '\0' in place, so that string_to_cstring() for these doesn't have to grow the string and place a NUL at end. > Actually, IMHO, we should disallow (both for this, and for string_make) > a simple default of 0 for 'flags'. We could redefine the meaning of string_from_cstring() to be "String from constant C-string. >> key = key_new_cstring(interpreter, "_message"); > IMHO, key_new_cstring should allow a "flags" argument, so that we can > pass in either a PObj_external_FLAG or 0; otherwise, it won't know > whether or not it needs to make a copy. The major problem here is, that its used to create hash keys, because the vtables are missing string-optimized variants. So each hash access like above at runtime needs a new PMC just to hold a String. We will probably have much more hash access with constant items at runtime, when objects are in, so I think its worth the optimization. The flags issue applies too, of course. >> * const_string_from_cstring - return cached constant string or create >> one > Instead of a new entry point, how about adding whatever behavior you > want here to be an added behavior of string_from_cstring, dependent on > what flags were passed as a third argument? Yep, that's better. leo
