This solution should allow to optimize (or even skip) dirty checking by analyzing effects in the GlobalState of the IntentExecution . In other words - the application would be able to analyze itself - and deduce changes Intent makes to the GlobalState. In the ideal implementation, we would need no dirty checking at all, and the Intent should perform as fast as vanilla js implementation.
Glossary
Intent - program / some piece of runnable code
IntentExecution - Representation of Intent execution which may change the GlobalState.
GlobalState - the current state of the Application
In case of Angluar 2.0 Components, we would be interested only in
Intents dealing (also indirectly) with the Components - Intents that would change the GlobalState (in terms of Angular 1.0: everything what is being $watched).
Deductive Implementation:
Knowing what is going to change requires analyzing the
IntentExecution. Basically this means analyzing the part of the
source code that is about to run the context of current state, and
deducing what the IntentExecution may be changing in the Global
State. Analyzing the data flow should be sufficient and fast. We would be able to mark what may be changed by the IntentExecution and perform dirty checking only on those objects.
Runtime Implementation:
Provided Angular could include a simplistic version of the Runtime and Application - performing only data flow and marking only changes made in the Global State. This implementation could yield higher performance as it should allow to be highly optimized by the JIT since it only would represent a data flow.
In case of very complex Intents or "ambiguous" Intents Angular could back-off to dirty checking implementation.
Implementation is based on CFG analysis. IntentExecutionAnalyzer would parse the AST of
the Intent and perform a data flow analysis AST 2 CFG (IntentExecution) looking for parts that could mutate the Global State.
It could do something similar to escope, cfg.js
This solution might be used in build time (there would be little chance of optimizing dynamic code) or build into angular (runtime).
At this point this is only a foggy idea, more details could be provided after trying to build first prototype.
I have to little idea about AST, CFG, DFA, NFA etc. to provide more help at this point.
Intents - Dirty Checking Optimization
This solution should allow to optimize (or even skip) dirty checking by analyzing effects in the GlobalState of the IntentExecution . In other words - the application would be able to analyze itself - and deduce changes Intent makes to the GlobalState. In the ideal implementation, we would need no dirty checking at all, and the Intent should perform as fast as vanilla js implementation.
Glossary
An example of Intent:
In case of Angluar 2.0 Components, we would be interested only in
Intents dealing (also indirectly) with the Components - Intents that would change the GlobalState (in terms of Angular 1.0: everything what is being $watched).
Deductive Implementation:
Knowing what is going to change requires analyzing the IntentExecution. Basically this means analyzing the part of the source code that is about to run the context of current state, and deducing what the IntentExecution may be changing in the Global State. Analyzing the data flow should be sufficient and fast. We would be able to mark what may be changed by the IntentExecution and perform dirty checking only on those objects.
Runtime Implementation:
Provided Angular could include a simplistic version of the Runtime and Application - performing only data flow and marking only changes made in the Global State. This implementation could yield higher performance as it should allow to be highly optimized by the JIT since it only would represent a data flow.
In case of very complex Intents or "ambiguous" Intents Angular could back-off to dirty checking implementation.
Implementation is based on CFG analysis. IntentExecutionAnalyzer would parse the AST of the Intent and perform a data flow analysis AST 2 CFG (IntentExecution) looking for parts that could mutate the Global State. It could do something similar to
escope
,cfg.js
This solution might be used in build time (there would be little chance of optimizing dynamic code) or build into angular (runtime).
At this point this is only a foggy idea, more details could be provided after trying to build first prototype.
I have to little idea about AST, CFG, DFA, NFA etc. to provide more help at this point.