UpdaterImpl is responsible for editor cell tree updates in reaction to model events, so I would maybe at first just add start/finish logging to the update() method.
If you mean just the painting, this is done in EditorComponent#paintComponent() (and also in #paintSelection() but that one doesn't do much so it's probably fast enough).
Thanks a lot. We are interested in the time it tacks to continue typing after a rebuild of the editor. So UpdaterImpl seems to be the right place, right?
Hard to say. In addition to AST rebuilding typing may be blocked by either a model update taking too long, or a background thread holding a model lock (either read or write) preventing the editor from executing a model update. For example, a change may invalidate a node and trigger a long-running checking rule that blocks the editor until it finishes (error checking can be interrupted between individual rules but not during the execution of a rule).
Also, maybe you don't need to actually change the code of Updater, you can add a listener to it (see Updater#addListener). You can also add listeners to ModelAccess (editorContext.getRepository().getModelAccess()) to get notified when a command or a write action is started and finished (commands and write actions both take model write lock). I'm not aware of any API to listen to read locks and checking rules though.
No.
Thanks for the quick answer :)
Can you tell me how I could integrate it (also MPS core would be okay for the test)?
UpdaterImpl is responsible for editor cell tree updates in reaction to model events, so I would maybe at first just add start/finish logging to the update() method.
If you mean just the painting, this is done in EditorComponent#paintComponent() (and also in #paintSelection() but that one doesn't do much so it's probably fast enough).
Thanks a lot. We are interested in the time it tacks to continue typing after a rebuild of the editor. So UpdaterImpl seems to be the right place, right?
Hard to say. In addition to AST rebuilding typing may be blocked by either a model update taking too long, or a background thread holding a model lock (either read or write) preventing the editor from executing a model update. For example, a change may invalidate a node and trigger a long-running checking rule that blocks the editor until it finishes (error checking can be interrupted between individual rules but not during the execution of a rule).
Also, maybe you don't need to actually change the code of Updater, you can add a listener to it (see Updater#addListener). You can also add listeners to ModelAccess (editorContext.getRepository().getModelAccess()) to get notified when a command or a write action is started and finished (commands and write actions both take model write lock). I'm not aware of any API to listen to read locks and checking rules though.
Ah, I see. Thanks for the details! So for now, I think we just approximate the time and try the listener solution you proposed!
@ Sergej The listener solution worked fine. We got our data. Thanks for the advice.