develooper Front page | perl.perl5.porters | Postings from February 2013

Re: PL_sv_objcount

Thread Previous | Thread Next
Ricardo Signes
February 28, 2013 21:48
Re: PL_sv_objcount
Message ID:
* bulk88 <> [2013-02-28T16:14:10]
> >You are arguing in favour of optimising about 30 *micro*-seconds from the
> >runtime of *trivial* one-liners (ie don't use Exporter or Config)
> Yes. Not everyone uses persistent processes. What will replace these
> 30 micro-seconds? Nothing? If they are trivial, why not deprecate
> and remove -e? It would make maintenance much easier to have
> newlines in code.

That is not a helpful argument, that is just snark.

The perl code can be made somewhat simpler by removing a piece of state.  There
is an extremely tiny change in teardown performance.  Given the amount of
complexity we have versus the number of experts, we should pick simplicity.

> >In the long game, maintainability and better algorithms win.
> *Who* will do the better algorithms? Maintainability is subjective.
> Lock the git, put a page welcoming existing Perl users to Rakudo and
> be done with it if it is unmaintainable.

Maintainability is subjective.  So is the value of any given optimization, even
though its effect under various circumstances can be measured.  Are you
suggesting that we might as well not allow anything just because we're not
going to accept keeping more code complexity to stave off 30μs?  That seems

> >Code reviewing micro-optimisations takes time from everything else.
> Removing optimizations to make life easy is a great plan.

What you might say with irony I say with conviction: Removing optimizations to
make life easy is a great plan.  At least so when the optimizations are

I don't know what about this thread has gotten you so displeased, but your
posts have become pretty unpleasant.


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