Front page | perl.perl5.porters |
Postings from January 2013
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.
-zefram
Thread Previous
|
Thread Next