JaroslavTulach
commented
1 year ago The desire for rationalistic solutions inside of us provides impetus to solve these issues properly by annotating nodes with AvoidIdInstrumentationTag. Incrementally we are supposed to improve our avoid instrumentation capabilities and we do it as following issues demonstrate:
-
4090
-
3977
Ultimately we don't need any throttling! Step by step we'll make annotation of our nodes better and better and everything will be fast and smooth at the end. However the question is: What happens when things go wrong before we get to such an ideal state? Clearly we are not there as issues like
-
7070
constantly remind us. We haven't reach the nirvana yet. What happens in such situations? The performance drastically decreases and poor Enso users get far from ideal experience. Can we do something about such known unknowns?
Yes, throttling is the solution. Such a pragmatic approach gives us a safety net to provide relatively acceptable user experience even in situations where avoiding instrumentation isn't done correctly. There is no reason why Enso users shall suffer for mistakes that we make - we should have the throttling safety net in place whenever we create a release.
Of course such pragmatic approach clashes with our desire for proper rationalistic solution. That's normal. However the answer is not to avoid the pragmatic choice - the answer is to design it in a way to rescue us, but give us enough information to incrementally improve our code - e.g. to place the AvoidIdInstrumentationTag where needed:
- verbosely logging that throttling was used
- turning the throttling safety net on only in releases, not daily builds
- annotating values with warnings to signal they are result of throttling
Are sample ways to allow us to act pragmatically, but strive for rationalism.
enso-bot[bot]
Occasionally bugs in instrumentation (like #7070, #4090, #3977) will lead to an increased number of expression updates. The amount of such updates can be so big that either instrumentation or IDE will give up and appear to freeze. In order to workaround this scenario, we could introduce in instrumentation updates throttling (per expression). Updates would be sent on two occasions: 1) a specified time window has passed and execution still continues 2) execution has finished and some updates haven't yet been sent
This should help with the impression that the execution continued as normal while giving us some leeway into fixing the underlying problem with less priority. Additional logging that monitors excessive updates must be added as well. The throttling would need to be carefully designed in order that IDE does not miss any crucial updates or creates inconsistencies, thus making things worse than before.