octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: For loop benchmarks between Octave versions


From: Rik
Subject: Re: For loop benchmarks between Octave versions
Date: Mon, 16 Jun 2014 17:39:37 -0700

On 06/15/2014 02:46 AM, PrasannaKumar Muralidharan wrote:
> The same test case took 2.35s in 3.6.4 while it took around 3.9s in
> 3.7.5. So bisected Octave code between release 3.6.4 and 3.8.1.
>
> CPU details:
> Intel Core i5. Clock speed set to 1.2GHz.
>
> The time taken to run the test case:
> ********************************************************************************
> 3.7.5 (did not note hg revision) -> 3.9s
> 16650:18d3c1b981e7 (3.7.3+) -> 4.13013s
> 16412:61989cde13ae (3.7.2+) -> 3.5439s
> 16295:4a1300ed5d3c (3.7.2+) -> 3.96383s
> 16216:70c47da7e02b (3.7.2+) -> 3.99449s
> 16183:359d56094efa (3.7.2+) -> 4.15015s
> 16168:8650eec57e9f (3.7.2+) -> 3.86547s
> 16161:b672afbb7c3c (3.7.2+) -> 4.06835s
> 16157:335041cc657a (3.7.2+) -> 4.06872s
> 16089:8a8e04aa3c98 (3.6.4) -> 2.34667s
> 16156:236be6179785 (3.7.2+) -> 3.85227s
> ********************************************************************************
>
> Hg bisect result:
> ********************************************************************************
> The first bad revision is:
> changeset:   16156:236be6179785
> parent:      16154:aa5e1e8dce66
> parent:      16089:8a8e04aa3c98
> user:        John W. Eaton <address@hidden>
> date:        Thu Feb 28 02:25:44 2013 -0500
> summary:     maint: periodic merge of stable to default
>
> Not all ancestors of this changeset have been checked.
> Use bisect --extend to continue the bisection from
> the common ancestor, 6a44bb3c9593.
> ********************************************************************************
>
> This result can be used to do further analysis.
>
> Note:
> I am continuing with the bisect further to find the change that causes
> the regression.
>
> Hope this helps,
> PrasannaKumar
>
I find that this changeset:

12920:5d18231eee00 Extend profiling support to operators.

produces a 50% slow down when using the for loop benchmark.  Unless we can
figure out a lower footprint way to do profiling we might be stuck with
this part of the slowdown.  There is still another 50% which seems to be
due to other accumulated cruft, i.e., I didn't find a smoking gun changeset.

--Rik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]