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

Re: PL_sv_objcount

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 28, 2013 15:08
Subject:
Re: PL_sv_objcount
Message ID:
20130228150822.GJ5653@plum.flirble.org
On Thu, Feb 28, 2013 at 09:48:37AM -0500, bulk88 wrote:

> Shutdown time is part of startup time. So it does affect one liners. 
> Running sv_clean_objs when PL_sv_objcount == 0, takes 1/10th to 1/100th 
> of a ms, or 200,000,000 to 20,000,000 instructions (2 GHZ cpu, and 
> instruction count is 100% useless, but it makes a point about numbers). 
> <sarcasm> I already know everyone here uses mod_perl, so why care about 
> one liners? they aren't real Perl users. Real Perl users lease another 
> blade when they need more performance or dont use Perl.</sarcasm>

Starting program: /home/nick/Perl/perl2/perl -Ilib -e 'use CGI'
[Thread debugging using libthread_db enabled]

Breakpoint 1, perl_destruct (my_perl=0x82f010) at perl.c:514
514     {
(gdb) p my_perl->Isv_objcount
$3 = 5


Pretty much *any* real world code of any form is going to end up with
PL_sv_objcount non-zero at destruction time.

> The ++/-- code is unmeasurable. It will be executed async to all the 
> other instructions ahead/behind it since its not related to any previous 
>   calculation/data. Regarding "nano optimization", I'll point out this 

It will, however, mean that that location has to be kept in the L1 cache.

> post 
> https://rt.perl.org/rt3/Public/Bug/Display.html?id=116443#txn-1185031 
> and 
> https://rt.perl.org/rt3/Public/Bug/Display.html?id=116443#txn-1184961 , 
> I won't make a comment on those 2 posts until more people respond in 
> this thread.

> "time= " is in seconds. Attached is raw data, no S_visit stats here 
> since they would triple to quadruple the .011 ms floor to 0.035-0.045 
> ms. With S_visit, raw data will have to be another post b/c of attach 
> size probably. The workload is "perl harness  base/*.t comp/*.t cmd/*.t 
> io/*.t op/*.t pragma/*.t" for both raw data files.


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)


In the long game, maintainability and better algorithms win.

Code reviewing micro-optimisations takes time from everything else.
It's not the right problem to solve first.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About