dart_eval
dart_eval copied to clipboard
ethanblake4
Potential optimization: Auto AOT when possible, and fallback to interpreted
For example, say I release v1.0.0 app with 10 pages. Then in v1.0.1, I change the UI (i.e. HomePage.build), and a few logic (e.g. HomePage.handleMyButtonClick).
Then, would be great to have all other pages (SecondPage, ThirdPage, ...) all in AOT, and also making all other untouched methods in HomePage still AOT, while only making HomePage.build and HomePage.handleMyButtonClick interpreted.
This is because an app will not change most of things in a hot update.
(Not sure whether I have mentioned this thought somewhere before)
The first part of doing this is covered in https://github.com/ethanblake4/dart_eval/issues/53 and https://github.com/ethanblake4/flutter_eval/issues/3 which I would like to have working in v0.6 (next major release).
The second part is basically some kind of auto-diffing to see what has changed since the last version. I have thought about that but it's definitely a 1.0 or post-1.0 feature.
The first part of doing this is covered in https://github.com/ethanblake4/dart_eval/issues/53 and https://github.com/ethanblake4/flutter_eval/issues/3 which I would like to have working in v0.6 (next major release).
Looking forward to that!
some kind of auto-diffing to see what has changed since the last version.
For a minimalist solution (which does create false positive though) - Maybe just generate bytecode for each and every code, and check equality?
For a minimalist solution (which does create false positive though) - Maybe just generate bytecode for each and every code, and check equality?
I don't really understand, can you explain more? What is it checking equality to?
So you are saying, generate bytecode for 'before' and 'after' case and then just see what has changed? Unfortunately i don't think that's possible due to the way the bytecode works (even a minor change to one part of the code can cause a lot of bytecodes to change, because they can store absolute offsets for functions/jumps which get 'pushed' by all previous changes)
I will add though, it maybe should not work like that because it's also annoying for incremental compilation. Maybe we can do that then if I end up changing it