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