You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For reducers that update the status bar or hud, it'd be nice if there were methods that they could implement that simply returned the relevant data.
The main motivator is to optimize things when we send multiple actions from the client. e.g. when typing we can send ViewPosChanged,ViewModified, QueryCompletions (QC). The first 2 are queued and then picked up by the ui blocking QC.
The reducers are called for every action, so in the case of things like the issues reducer, the status is computed 3 times. We can't always pre-compute the data because it might depend on the current state, and so if it takes more than a few milliseconds, it quickly adds up. In the case of the issues, I recently found a bottleneck where the computation took ~90ms, which multiplied by 3 meant the request took ~270ms on top of actual work.
It'd be better if QC would go first so other actions don't block it
We already know which action's ui updates will get discarded so it'd be nice if reducers didn't have to do anything in these cases.
This would also simplify things because the reducer no longer needs to make sure they always update the state even if they return early.
The text was updated successfully, but these errors were encountered:
* update deps
* make mg.Issue usable as errors
* add support for MARGO_NO_RESTART env var and `//margo:no-restart` comment
* add mgutil.AtomicInt
* add prodile node for kimporter.parseDir
* change profile tree indentation to 2 space
* expose all reduction actions via Ctx.Acts
relevant: #88
* fix compilation error on Windows
* remove travis config, it's been replaced with a GH action
* Temporarily™ disable some tests on Windows
For reducers that update the status bar or hud, it'd be nice if there were methods that they could implement that simply returned the relevant data.
The main motivator is to optimize things when we send multiple actions from the client. e.g. when typing we can send
ViewPosChanged
,ViewModified
,QueryCompletions (QC)
. The first 2 are queued and then picked up by the ui blockingQC
.The reducers are called for every action, so in the case of things like the issues reducer, the status is computed 3 times. We can't always pre-compute the data because it might depend on the current state, and so if it takes more than a few milliseconds, it quickly adds up. In the case of the issues, I recently found a bottleneck where the computation took ~90ms, which multiplied by 3 meant the request took ~270ms on top of actual work.
It'd be better if
QC
would go first so other actions don't block itWe already know which action's ui updates will get discarded so it'd be nice if reducers didn't have to do anything in these cases.
This would also simplify things because the reducer no longer needs to make sure they always update the state even if they return early.
The text was updated successfully, but these errors were encountered: