Front page | perl.perl5.porters |
Postings from January 2013
On 01/31/2013 11:45 AM, Zefram wrote: > Steffen Mueller wrote: >> 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. I just pushed a branch smueller/likely that adds a bunch of LIKELY and UNLIKELY's. Not all of the type ux < 0x? yet, though. >> 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.) These are in the branch. >> 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(). Not in the branch. > 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. Not in the branch either. So far, my trivial and meaningless benchmarks have not uncovered any effect of the hints on linux/gcc4.7.2/x84_64. I did not look at the generated code. --SteffenThread Previous | Thread Next