Performance of the SB-Prime Editor

[Scout]

One of the very few good things that Q&A has brought to the SmallBasic language is the removal of the 64KByte limit for source code when publishing/importing.
I mean this came with the change of IDs from ABC123-0 to ABCD123.000.
Now really big and good programs can be published if someone has used SmallBasic in a specific topic.

However, long execution times occurred when loading the 167kB program Calendar PTKR773.0000, as well as when searching for "follow" between lines 500 and 1600.
Searching is significantly faster with the standard SmallBasic.
I hope it's not a big problem.


Update: The search function is fast again. I don't know what that was about.
             However, the loading function is still slow. Significantly faster in standard SmallBasic.

[litdev]

Hi, no idea why load should be slower; under the hood I use the same code, but will look into it.
Thanks for raising issue.

A quick look shows it is not the download, but the window lexer that formats the text (e.g. copy source to a new window).  I use something called Scintilla for this in SB-Prime - it parses the whole file for intellisense, code coloring etc and this takes time, there may be some specific bottlenecks or optimisations I can make.

[Scout]

I reset my detailed DarkTheme (don't like it anymore anyway) and get the original SB colors. However, it doesn't change the different loading times from the hard drive.

By the way: The recent file list was also deleted.

I think the function for displaying and suppressing code blocks takes a lot of time.

[litdev]

Updated SB-Prime to better handle lexing of large files.  Lexing is done pretty much character by character using regex to identify numbers keywords etc.

My fix is to limit this to 1000 characaters (the ones usually visible on cuurent page as required).  Sometimes the lexing may lag a bit (no coloring until a bit of scrolling) when more than 1000 characters on a page with long lines maybe, but overall I think it is an improvement.

This should also fix formatting, code folding etc - hopefully.

[Scout]

Lightning fast and no noticeable restrictions - perfect!!! 

[Scout]

This program from ArdiArdi is a killer program for SB-Prime: NKMG653.000
It has a line of 100000 characters.
Standard Small Basic has no problems with this.

[litdev]

Hi Scout,

I just seen this.  I cannot see an easy way to cope with this in general.  However, when I did the last fix for the lexing limiting it to 1000 characters that I guessed would be OK for most pages, I did add a setting to modify this value.

If you look for the settings config file somewhere in %appdata%.  Mine is at "C:\Users\steve\AppData\Local\LitDev\SB-Prime.exe_Url_5ge2lq5zwv0dmwwzggpbckh41oxaqouj\1.1.9.0\user.conf".  Check the date as there may be more than one, if different versions have been installed.

In this file modify the following setting from 1000 (default) to 100000

            <setting name="MaxStylingCount" serializeAs="String">
                <value>1000000</value>
            </setting>

This will slow the large file cases a bit, but will work for this ArdiArdi case.  In general a line with 100000 characters is not a great way to add data to a code - a file would be better, but I understand why it is done this way.

I can see that if a single line exceeds the maximum, the code will badly struggle as you show.  I could check the max line length when a file is loaded, but not if a line is pasted or otherwise dynamically changed.  Continually checking would of course also slow things, but I may have a go.

UPDATE

I have uploaded a version that does check line length and seems to work well, so I recommend remainin g with the default value of 1000 and updating to latest update, easiest using the Adavnced->Update option.