Open vince-fugnitto opened 4 years ago
Yes it is expected, otherwise language specific preferences won’t be applied to monaco. Preference configuration can define which preference is overridable. Do you experience any perf issues?
Yes it is expected, otherwise language specific preferences won’t be applied to monaco. Preference configuration can define which preference is overridable. Do you experience any perf issues?
It was initially brought up by internal customers, I believe they had a noticeable performance decrease (~2 seconds) each time it was updated through the user interface.
Could it be reproduced openly? then we can take measurement and see what can be done about it.
Could it be reproduced openly? then we can take measurement and see what can be done about it.
Is my small test enough? It creates a command which updates one such preference (editor.acceptSuggestionOnCommitCharacter
). Should we try and find a more regular example?
@vince-fugnitto I meant the test which will cause performance issues. If something is executed multiple times but fast then it is not the issue. React recreates VDOM multiple times sometimes on each mouse move (think about the navigator selection) but we are not going to rewrite it just because it seems to be excessive thing to do.
Description
When a preference is updated (ex:
editor.acceptSuggestionOnCommitCharacter
) through theset
method, multiple change events are emitted for every language. Is this the intended behavior? (it seems excessive)This seems to only occur for language specific preferences (or those from Monaco). It did not occur for example for the following preference:
workspace.preserveWindow
.Steps to Reproduce
A command was created which reads the current preference value, updates it, and listens to the change event (which is then logged):
Vince: Test Preference
Log