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
{{ message }}
Repository navigation
Minor code efficiency issue, use of LineIsMultiLine() #1125
While working on #1108, while proposing to have InsertLineAbove() utilize GetBeginningOfLinePos() since it performs the exact same loop backward through the buffer searching for a \n, I was almost going to leave the original reference to LineIsMultiLine() in InsertLineAbove(), though it also occurs in GetBeginningOfLinePos().
However when I look at the code for LineIsMultiLine() it is itself a search through the buffer for a \n. Statistically, if LineIsMultiLine() finds a \n then there is now going to be Ta + Tb time spent searching for \n instead of just Tb time spent, where Ta is time spent to find the first \n in the buffer and Tb is time spent to find a \n under the specific scenario of the function. In the case where no \n is found, LineIsMultiLine() will touch every character in the buffer to confirm that, where as in the specific scenario of the function will result in a variable number characters being checked, from 0 through all of them, depending on the scenario.
Is there a reason for this approach?
Is there a downside to removing the use of LineIsMultiLine() when making changes to such functions?
I originally introduced LineIsMultiline when I started working in improving vi-mode to more closely work with multiline buffers. I did that so that I could tailor the code in generic methods that are also used in the Emacs-mode because I did not want to change the behaviours of these functions.
Most of the time though, I find it best to write algorithms that natively work irrespective of the fact that the buffer contains a single line or multiple lines, without resorting to using LineIsMultiline.
At the end of the day, the unit tests will tell you if you can shortcut and improve the code.
Activity
springcomp commentedon Nov 10, 2019
I originally introduced
LineIsMultilinewhen I started working in improving vi-mode to more closely work with multiline buffers. I did that so that I could tailor the code in generic methods that are also used in the Emacs-mode because I did not want to change the behaviours of these functions.Most of the time though, I find it best to write algorithms that natively work irrespective of the fact that the buffer contains a single line or multiple lines, without resorting to using
LineIsMultiline.At the end of the day, the unit tests will tell you if you can shortcut and improve the code.
Remove LineIsMultiline use multiline agnostic algs (PowerShell#1125)
Remove LineIsMultiline use multiline agnostic algs (PowerShell#1125)
Remove `LineIsMultiline` in favor of multi-line agnostic algorithms (#…