Sat 20 Feb 2016 02:46:40 PM UTC, comment #9:
Probably best to wait a bit. For 4.2 I mean to have Octave move to compatibility with Matlab with respct to 'hold all' and this will simplify _next_line_style_.m.
|
Sat 20 Feb 2016 09:01:38 AM UTC, comment #8:
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++.
|
Mon 15 Feb 2016 11:50:07 PM UTC, comment #7:
I think the entire topic of slow graphics belongs on the Octave Projects page. If there are specific slowdowns that can be addressed with a change to one file then they can get their own bug report. But otherwise I think a coordinated approach touching many files will be necessary.
|
Mon 15 Feb 2016 09:35:10 PM UTC, comment #6:
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.
|
Sat 13 Feb 2016 09:50:54 AM UTC, comment #5:
Here is a patch ready for feedback.
Before:
After:
The optimizations are:
1. Call _go_line_ directly instead of calling line.m many times. (This is in bug_plot2vm.cset -- all other changes are in bug_47052_v1.cset)
2. make _go_line_ accept a matrix consisting of many lines, instead of a single line
3. Instead of creating a new line from scratch each time, clone the first line and change its y properties. (This seems to make the most difference, but I can't see why.)
Things still to do include:
- Calculate line style and line marker (_next_linestyle_ into C++); handle colours with "hold all"
- Set xsource correctely for each line
Questions I have are:
- Is there an obvious flaw in doing this?
- Is there a better way of doing this?
- Is the an underlying reason for the slowness that should be fixed instead of worked around?
- Once this is finished, should it also be done for primitives like surf?
(file #36326)
|
Wed 10 Feb 2016 01:01:09 PM UTC, comment #4:
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.
|
Wed 10 Feb 2016 07:55:58 AM UTC, comment #3:
I've confirmed relative behavior similar to what you are describing. I suspect that the slowness comes about because of inefficiency in the figure properties. Transposing results in many more individual lines in one case and those lines probably need to be entered into the figure's children, all properties initialized, etc.
Your changes sound reasonable, but at the same time don't sound like they would be the source of such slowness. I wonder how memory management is done. Is it efficient speed-wise? Space-wise? Etc.
|
Thu 04 Feb 2016 12:15:05 PM UTC, comment #2:
Oops. I'm trying again to upload the patch.
(file #36247)
|
Wed 03 Feb 2016 10:01:33 PM UTC, comment #1:
Is there a patch that failed to get uploaded? It is mentioned in the text.
|
Wed 03 Feb 2016 11:26:38 AM UTC, original submission:
On my system,
yields about 9.7 seconds, whereas plotting the same amount of data with fewer rows
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.
|