Conversation
|
This pull request introduces 1 alert when merging cb4aca2 into 8b31696 - view on LGTM.com new alerts:
|
|
Hi! In my opinion, the main slowdown factor is the lack of batch processing of pixel data. Since it uses pointers to color functions, this results in an expensive function call for every pixel processed. I can illustrate this with a small example: test results: function call now inlined 3x speedup! P.S.
|
|
So far I've only been making cursory glances on instructions/lines that could be moved around to take better advantage of of auto-vectorization. I plan on doing more substantial changes, but I want to learn a bit more about the project before going a little more into adjusting the architecture of things. I'm well aware of how pointer chasing can ruin performance.
|
Only for C++ code. |
446cc31 to
aa46274
Compare
|
Requirements file added and spaces->tabs fixed. |
|
This pull request introduces 1 alert when merging aa46274 into 0576fa8 - view on LGTM.com new alerts:
|
|
Please check LGTM warning about |
First script does a render on all of the render tests. Second script use data from the first to show comparisons in runs. Read the headers of the scripts for details Part of synfig#1775
the `m**` values were being referenced in a constant manor. It's best to avoid writing data to another variable (multiple times) if a `const` can suffice. closes synfig#1175
aa46274 to
94adb2e
Compare
|
whoops, that was a leftover form a previous iteration. It's gone now. |
|
Merged. Thank you! |
I didn't see much of a noticable speedup except for about three of the test .sif files. This does make things cleaner though. It was mentioned that maybe these should be removed in synfig#1778
As mentioned in #1775, the perf improvement here is very miniscule, but I'd like to push in the two scripts I wrote that should help with measurement. I plan on adding some more PRs that should be more significant.
So show you how tiny the change has been, here is some output from the

view_comparison_graph.pyscript: