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
Performance difference with [] on typed arrays vs. typed array views #9596
Comments
We probably need to optimize at the operator level ([], []=) instead of only at the level of the native. |
This comment was originally written by @tatumizer "View" is very powerful concept. Simplifies programming tremendously. Please make it perform exactly as array, whatever it takes. Probably, doing this on operator level is the only choice. |
Yes, doing it at the operator level would work. Before doing that I'll look into improving constant propagation and range analysis to eliminate the if-statement completely. If that works out nicely and covers all interesting cases, we could avoid special-casing for the [] and []= operators on views. Added Started label. |
cc @johnmccutchan. |
https://code.google.com/p/dart/source/detail?r=20914 improves typed array view performance by eliminating more range checks. Of course, it is not always possible to eliminate the range check, but it should help in the reported example. There may be still a performance difference due to the start offset that needs to be added when loading from a view. |
Added Fixed label. |
This comment was originally written by @tatumizer Performance of subscript for uint8 view is much slower than subscript for underlying typed array. (6.1 ns/byte vs 2.3 ns/byte) In other words, it doesn't look optimized at all. |
Set owner to @sgmitrovic. |
The main performance drop is still caused by not being able to eliminate explicit range checks and by some register allocation issues. Example program below. import 'dart:typed_data'; main() { foo(list, size, iterations) { |
The reason we can't eliminate the range check in this example is that the compiler can't deduce the connection between 'size' and 'list.length' inside function foo. If you replace for (int j=0; j<size; j++) { with for (int j=0; j<list.length; j++) { the performance difference should go away. Optimizing the example as shown would still be possible if the compiler could optimistically hoist the range check out of the loop. The current implementation of bounds-check elimination is not able to do that. |
Removed Priority-Medium label. |
@fsc8000 Is this still an issue? |
Yes, there is still a difference, but t is much smaller now though. I see around 30% depending on inlining/OSR instead of the original ~3x slowdown. |
Closing as the original large slow-down seems fixed. |
The attached example shows a performance degradation when using an array view.
In the view case, the optimizer is not able to eliminate the if-statement for the range check from the inlined body of Uint8ArrayView.[]:
if (index < 0 || index >= length) {
_throwRangeError(index, length);
}
Attachment:
uint8listview.dart (616 Bytes)
The text was updated successfully, but these errors were encountered: