bugGNU Octave - Bugs: bug #35400, Performance of in-place operations


bug #35400: Performance of in-place operations

Submitted by:  Rik <rik5>
Submitted on:  Mon 30 Jan 2012 01:45:07 AM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sun 20 Nov 2016 02:50:16 PM UTC, comment #3:

This certainly could be fixed, but it will require medium to major changes to how the parser works. This isn't necessarily a bad thing. There is a subsasgn bug already out which would require the same change. There have been requests to recognized true uint64 bit constants which the parser currently converts to double, etc.

Rik <rik5>
Project Administrator
Sat 19 Nov 2016 08:10:48 PM UTC, comment #2:

This issue is still (partly) present in Octave 4.2.0.

I now get the following result from the test script:

So we somehow improved the performance of the second command to match the third one. But the first one is still slower by a factor of two.

Would it be feasible at all, to perform the first (and most general syntax) command "x = x + 1" as an in place accumulation at all? If "no", then let's close this issue. If "yes", then let's keep it open.

Hartmut <hardy>
Mon 27 Jan 2014 02:29:54 AM UTC, comment #1:

I get roughly the same results, still an issue in the current development version.

Mike Miller <mtmiller>
Project Administrator
Mon 30 Jan 2012 01:45:07 AM UTC, original submission:

The increment operation can be coded a number of different ways in Octave.

After benchmarking the operations, it turns out that the third form is significantly faster (> 2X) than the others. It is disconcerting to have the performance depend so heavily on exactly what construct the coder uses.

The reason for the performance speed-up is the work done by Jaroslav which means that the third case uses in-place accumulation rather than assigning to a temporary array.

One possible solution would be to have the parser recognize the first two forms as in-place operations and map to the existing code used in the third form. This issue applies to any of the operators which also have in-place forms (+=, -=, *=, /=, &=, |=, ^=, etc.)

I'm attaching a benchmark script I used (bm_accum.m). The test results are:

x = x + 1;
Elapsed time is 1.7 seconds.
Elapsed time is 1.8 seconds.
x += 1;
Elapsed time is 0.69 seconds.

Rik <rik5>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #24912:  bm_accum.m added by rik5 (147B - text/x-octave)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-27 mtmiller StatusNone => Confirmed
        Release3.6.0 => dev
    2012-01-30 rik5 Attached File- => Added bm_accum.m, #24912

    Back to the top

    Powered by Savane 3.3