Replies: 1 comment 3 replies
-
@MShark67 Good to hear from you. Have you seen the two commits in relation to:
Regarding your proposal I am not sure you need to change SetLine. Both ScanRange and ScanFrom use NextToEOL. When NextToEOL is called we are only interested in the the last token and the range info. You could set a protected variable in NextToEOL e.g. (FScanningToEOL) to indicate that Next is called from NextToEOL and do whatever optimizations based on that variable. procedure TSynCustomHighlighter.NextToEol; |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The ScanFrom and ScanRanges methods of SynEdit both scan through lines with the intent of setting each line's "Ranges" property. If a highlighter knew that it was being asked to do a "range only" scan, it could optimize for that need. A very quick improvement with the SQL highlighter shows roughly a 50% improvement in scan time with this change (and I'm sure it could be more.)
Proposal:
Add a protected boolean field called FRangeOnly to TSynCustomHighlighter. This would be false by default and only set in calls to SetLine with a default value of False. e.g.:
procedure SetLine(const Value: string; LineNumber: Integer; RangeOnly: Boolean = False); virtual;
No current highlighter overrides this method, so no highlighters would need be changed.
Then modify ScanFrom and ScanRanges to set this flag to true in their SetLine calls.
This should have no affect at all unless a highlighter has been modified to handle FRangeOnly.
Any thoughts or feedback appreciated! If it seems a good idea, I'll pr with the changes along with an optimized SQL highlighter. Other highlighters could be optimized on a case-by-case basis.
Beta Was this translation helpful? Give feedback.
All reactions