I came across this bug report again.  Without knowing that it existed, I also came to the conclusion that _go_line_ should be called directly.  That change was made recently

changeset:   26210:da75dfccf14b
user:        Rik <rik@octave.org>
date:        Wed Dec 12 11:25:38 2018 -0800
summary:     __plt__.m: Improve performance by 35% by calling __go_line__ directly.

Rewriting the C++ deserves its own project, or at least something on the patch tracker.

Marking this bug as fixed and closing report.

I'm currently in the process of writing _next_line_style_ in C++, and that will also require _pltopt_ to be translated to C++.

Since this is becoming rather a large patch, and Rik was flagging a major rewrite, I'm not sure if I should go ahead. My current patch meets my needs.

If there is to be a major rewrite, some of the things I would suggest are:

- Each class like 'line' could have static defaults, with only those that are overridden being initialized for each object.

- It may be faster to have named constants instead of strings for many of the properties.  It would be just as slow when accessed from .m files, but faster from C++.

- It may help to avoid rendering partial figures until they are fully drawn.

- Primitives like _next_line_style_, line and patch should probably be in C++.

Slightly OT, but Octave is significantly, if not a magnitude or more slower than Matlab when drawing series of patches and esp. drawing grids with surf, mesh and similar functions.

I can dig up some example grids + code to illustrate this.

Thanks for looking at the patch, Dan.

The patch eliminates the per-line processing of line.m which essentially just does input validation and then calls _go_line_.  On my system, the patch improves the speed from about 9.7 seconds to about 5.7.  I agree that there is still lots of room for improvement, which is why I didn't mark this as "Patch submitted".

I'm not sure about the memory management.  I'll look out for that when I next look at this code.

Oops.  I'm trying again to upload the patch.

(file #36247)

On my system,

a = rand (48, 365);
tic; plot (a); toc

yields about 9.7 seconds, whereas plotting the same amount of data with fewer rows

tic; plot (a'); toc

takes less than a second.

The low-hanging fruit (about 40% of the time) is taken in the attached patch, which calls _go_plot_ directly instead of incurring the overhead of calling line.

Most of the rest of the time seems to be taken up by gh_manager::make_graphics_handle (I suspect it is because each property is quite "heavy"), and by set_[xyz]data.  I hope to write a patch to avoid repeatedly calculating the x limits for each line, and only update the axis y limits once instead of once for each line, but it is looking like that will require a lot of changes.

To speed up make_graphics_handle, I'm toying with the idea of having a "default" object of each property for each object (like a default "line":"marker"), and the graphics objects only instantiate their own properties if a non-default value is assigned.  Does that sound like a suitable approach?

The other thing I would like to do is replace the string labels for properties by an enumeration.  I realise that the .m files will have to stick with string labels, but all the string comparisons seem wasteful.  Do people have thoughts on that?

Rik said that the OpenGL graphics needs an overhaul, but I don't think this is toolkit-specific.  I first noticed it using gnuplot, and now see it using FLTK.  Also, the actual rendering is quite fast.