dart_eval
dart_eval copied to clipboard
ethanblake4
Potential optimization: Use integers instead of Strings to look up methods
For example, strings here: https://github.com/ethanblake4/dart_eval/blob/c5795f1e284a46e44d2f9c30b73eebc3b2787fc3/lib/src/eval/shared/stdlib/core/map.dart#L20 "length" can become (index) 2 etc.
This must be combined with the https://github.com/ethanblake4/dart_eval/issues/20 because it is so error-prone to manually assign numbers.
If doing https://github.com/ethanblake4/dart_eval/issues/65, this may be of less priority, since lookup happens in secondary isolate instead of the main isolate, so may not be the bottleneck.
@fzyzcjy could you post the benchmarks that indicate that this sort of micro optimisation will have a positive improvement in performance?
@maks These are just potential optimizations :) But we all know, strings are bigger than integers, so storage will be bigger and cpu will be slower. Yes it is a question how much it improves, so we may need to check it before implementing it.
Looking up functions/properties by index is already done for classes defined inside of dart_eval when the concrete type is known. What you're talking about though, if I'm getting this correctly, is actually a sort of global string hash for function/field names? I'm not too sure that would work since you'd have to allocate large arrays for each object and populate all the missing values with null... or maybe I'm not understanding this right. Or maybe there's some way we can reuse indices by checking for collisions... the problem is that you can implements any class in Dart so I don't really know if that's possible.
Well I mean, at least, case 'length' becomes case 2. The "2" is generated by the compiler instead of "length" whenever it sees String.length.
Oh, I see. So it's not an array lookup but just changing the Map key. That would work but probably very minor performance improvement.
At least bytecode size may be smaller.
Anyway this is just "potential" optimization :)