Posted 19 years ago
by mbren
I have noticed significant performance degradation while entering text into the editor if the current edit line contains the StartScope Token for a large scope (such as the ‘{’ character of namespace or class declaration in a c# file). Entering text before this Token appears to cause the whole state to be reparsed, so in complex documents this causes the editor to appear to freeze as it reparses the whole document after every character entered.
This reparsing does not seem to occur if text is entered on the line preceding the Token. If you require I have some profiler snapshots of entering a single character on the same line as the token and on the preceding line. When a character on the preceding line is entered method _19._1() and its child methods execute in 0.0293 seconds, whereas when the same character is entered on the same line method _19._1() and its child methods execute in 2.6308 seconds.
It is worth noting that this slowdown does not occur on a charater removal from inside an existing token - (though deleting a character which removes a token does cause the same performance degredation). It would be expected that as the affect of adding and removing a character could be to create or remove an existing token (therefore modifying the token stream) the performance would be the same for both of these operations - this is what leads me to suspect this could be a bug - or at least an inefficiency in the additive editing operations that is currently optimised (at least to some degree) in the subtractive editing operations.
Is there a method or workaround to prevent the contained state from reparsing if the token has only changed position on the line (ie. by having text entered before it). Is this the designed behaviour or is this considered a bug? Is this something that is likely to be looked at and improved in a future release?
Thank you for your great support, and a great product.
[Modified at 06/22/2005 07:01 PM]
[Modified at 06/22/2005 07:03 PM]
This reparsing does not seem to occur if text is entered on the line preceding the Token. If you require I have some profiler snapshots of entering a single character on the same line as the token and on the preceding line. When a character on the preceding line is entered method _19._1() and its child methods execute in 0.0293 seconds, whereas when the same character is entered on the same line method _19._1() and its child methods execute in 2.6308 seconds.
It is worth noting that this slowdown does not occur on a charater removal from inside an existing token - (though deleting a character which removes a token does cause the same performance degredation). It would be expected that as the affect of adding and removing a character could be to create or remove an existing token (therefore modifying the token stream) the performance would be the same for both of these operations - this is what leads me to suspect this could be a bug - or at least an inefficiency in the additive editing operations that is currently optimised (at least to some degree) in the subtractive editing operations.
Is there a method or workaround to prevent the contained state from reparsing if the token has only changed position on the line (ie. by having text entered before it). Is this the designed behaviour or is this considered a bug? Is this something that is likely to be looked at and improved in a future release?
Thank you for your great support, and a great product.
[Modified at 06/22/2005 07:01 PM]
[Modified at 06/22/2005 07:03 PM]
