Steffen Mueller wrote: ># define SvGROW(sv,len) (UNLIKELY(SvLEN(sv) < (len)) ? >sv_grow(sv,len) : SvPVX(sv)) That's a good one. >[1] Which makes me wonder whether gcc would make the same assumptions >about ternaries as it does with if(){}. Presumably yes. Yes. if() and ?: only differ in surface syntax; the grammar part of the C frontend reduces them to the same abstract representation. >Is it a fair assumption to think that most characters we deal with >are < 0x80? Yes. Not only is this mostly the case for users' textual data, it's especially the case for machine-readable data, seen in all sorts of file formats and APIs. The latter, in particular, are liable to be performance-critical. >Another fun one: What about UNI_SKIP? Each uv<0xwhatever is LIKELY. >Anything taint related could be considered unlikely. Another >judgement call: Do we want to slightly pessimize the already-slow >taint logic Yes. Tainting is exceptional, and involves some explicit acceptance of a performance penalty. We should minimise the cost of this feature to code that doesn't use it. (In fact, a config option to omit the taint facility entirely would make sense, for the not-terribly-uncommon case of a performance-sensitive user compiling eir own perl.) >Would it be beneficial to add a separate function that only allocates >a new SV without checking whether we should reserve string space? Yes. newSV() is a relic from very old Perl where strings made up a greater proportion of the data processed. We can separate it into newSVnull() and newSVbuffer(). The former already has a mortalising counterpart in sv_newmortal(). By the way, LIKELY() and UNLIKELY() should probably include an implicit cBOOL in their expansions. As it is now, LIKELY(ptr) is saying that we expect the pointer to have the value 1, not merely that we expect it to be non-null. -zeframThread Previous | Thread Next