develooper Front page | perl.perl5.porters | Postings from October 2014

[perl #115746] [PATCH] clean up inline string comparisons in gv_fetchpvn_flags

Thread Previous | Thread Next
Tony Cook via RT
October 27, 2014 04:29
[perl #115746] [PATCH] clean up inline string comparisons in gv_fetchpvn_flags
Message ID:
On Mon Jul 29 23:26:02 2013, tonyc wrote:
> On Fri Nov 16 18:49:50 2012, bulk88 wrote:
> > On Fri Nov 16 18:31:40 2012, bulk88 wrote:
> > > This patch is also a syntax error in C++ because of cutting off the
> > > (unnecessary) null char in the initializers so as is it can not be
> > > applied. :-/ Other questions remain in this ticket without a conclusion.
> > The fix would be a INSTREQ_1,INSTREQ_2, INSTREQ_3, upto 8 I guess (after
> > that efficiency starts to go down hill on 64bit machine) macros since
> > variadic macros arent portable. That would also cut down in the large
> > amounts of ifdefs my patch has (and probably more if a solution is found
> > in this ticket).
> The new code introduced does produce some nice generated code, but it's
> unsafe (which could be worked around) and duplicative (which your macros
> could fix.)
> The main possible performance issue I can think of would be the extra
> memory access (probably from the internal cache) required on platforms
> that do allow unaligned memory acceses, potentially for both sides of
> the comparison.  This may explain the mixed results from benchmarking.
> Where the name of the variable isn't one of the specials, the variable
> name probably *won't* match on the first letter (except for _), so the
> change won't produce a large performance win even ignoring the unaligned
> accesses.
> So I'm rejecting the patch on this ticket.

There's been no follow-up, so closing the ticket.


via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About