-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Basic image blur algorithm runs 20-100x slower in Dartium than JS #5661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Adding repro which runs from the local filesystem. Attachment: |
I expect every single access to the Uint8ClampedArray (pixel data) and the Float32Array (pixel data window) to go through a native call since Dartium is not using any of the scalar list support. There are two things to be done here:
We will continue the VM investigation of standalone performance here. |
Adding clamped Uint8ClampedList to VM. Will follow by optimizing access to it. |
Issue #7347 has been merged into this issue. |
Optimized access with r16666. Waiting on Dartium to switch to VM's clamped array Set owner to [email protected]. |
This comment was originally written by [email protected] Should have been fixed now. Please, reopen if not the case. Added Fixed label. |
Attached is a simple image blur application using a fairly object-oriented (yet usually efficient) scanline blur implementation.
The code is implemented in both Dart and Javascript, with absolute minimal delta.
On my machine, Dartium takes ~5000ms to process the image, dart2js is ~150ms and vanilla JS is 50ms.
Note that changing the pixel data types from Uint8ClampedArray (native type for Canvas data) to List<int> and an intermediate data list from Float32Array to List<int> moves this from 5000ms to 1600ms. The Uint8ClampedArray conversion is problematic as it incurs a heavy duplication of the image data which is not accounted for in the 1600ms. These arrays should really remain in their native data type as much as possible.
I'm sure there are many optimizations that could be done to this code, but it doesn't feel so terribly inefficient to warrant these performance differences.
Attachment:
blur.zip (223.55 KB)
The text was updated successfully, but these errors were encountered: