Re: For loop benchmarks between Octave versions

[Rik]

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
Thanks for working on this issue.  Since this was just a merge of code it
is most likely that the changeset which caused the problem is still
backwards in time on either the stable or development branch.  Maybe follow
Mercurial's guidance and continue with 'hg bisect --extend' to see if it
can locate it.

I see that the parent revision of the merge was 16089 which was just a
changeset to tag the 3.6.4 release which was itself 16088.  Since we know
that 3.6.4 had an acceptable running time, the problem changeset is likely
to be on the development branch.

--Rik