-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add EOS optimization #114
Comments
Initial step can be self detaching the node from its dependencies if it is considered done ("take(N)" for example or "happened"). Currently the same is done by observer nodes. Reactive graph visualization even trivial one could be very useful for this feature. Also, if const propagation will be done in "update()", then signals should have additional "has_changed" flag to be checked by dependencies. So constness propagation and change propagation could be separated. Now the fact of calling "update()" is considered as a fact that at least one of the dependencies has changed. Additional thought is - to be able to replace a node with a different one (parent node, never node, constant node) we need to introduce additional level of indirection. I have no idea how it impacts performance and how to deal with ownership if this new feature will replace current shared_ptr based model. |
Instead of additional level of indirection, specialized std::shared_ptr analog can be introduced on top of nodes slot_map. node_ro_ptr, node_rw_ptr should contain just id in slot_map and inc/dec In case of There is an idea of caching of all existing constant nodes to reuse them (link all |
New idea (not sure it is viable): recreate const and never nodes on top of the existing nodes using placement new. It should be ok, because such nodes should use the same or less amount of memory. Need to check how shared pointers handle the fact that object they pointing suddenly changed its type. Anyway, const detection and propagation comes first, const tree minimization - second. |
Description
There are some common cases when computation graph is complete:
ureact::once
has already passed a single event ormake_never<int>()
Further development of the idea can be seen in RxCpp.
It has
completed
as a first class citizen, so it is no longer an optimization, but part of some algorithms likecombine_latest
,with_latest_from
etc.But it is subject for another issue.
The text was updated successfully, but these errors were encountered: