Basic V Performance

On a Pi with the current official build, setting Basic$Crunch True, causes the program to be crunched on load. In my case giving considerable size reduction (35%) and noticable performance benefit as a result.

BUT using CHAIN to restart the program (with or without any code differnces), causes the program to be loaded without being crunched. (thus losing the benefits).

In fact, using CHAIN under any circumstances seems to cause the chained progam not be to crunched, even though the original (chaining) program was auto-crunched.

Yes, that is what is to be expected. Only when the program is run with ‘BASIC -quit’ is it auto-crunched. That is the default when double-clicking a BASIC file or using 'Run <filename>' in a !Run file.

BASIC’s own CHAIN statement is quite seperate and pretty well obsolete these days IMHO. For what reason are you using it? There might be an alternative.

The primary data of most of my programs is held in memory at, say, LOMEM address &20000. This gives me the simple option to change the program on the fly without losing any of the primary data.

When told, the program simply CHAINs a new version of itself without losing any essential data and without needing disc accesses. The data just sits in memory all the time.

For example, an HTTP server can be upgraded on the fly without losing the port binding or any incoming TCP data.

Neither book overtly states what version it is for

Not really, but the Reference Manual history appendix ends at 1.05. I have given 1.04 for the Guide because other documents I have with an almost identical set of changes to those in the appendix do specify that version. Fallible memory also tells me that 1.03 was never in a commercial Archimedes. ;-)

This gives me the simple option to change the program on the fly without losing any of the primary data.

An interesting problem. A dynamic area for the data comes to mind or perhaps a temporary file in RAMFS. In either case you would use *BASIC -quit to run the new version and a system variable¹ to hold the pointer or name. It has got me thinking. ;-)

¹ Edit: I can think of ways to avoid this.

I am going to suggest that auto-crunch was disabled deliberately because there are just too many bugs in it!

It just does not do the job! And to use it every single branch of a progam would have to be re-tested

This post was edited 6 hours later to withdraw the comment. See below.

I am going to suggest that auto-crunch was disabled deliberately because there are just too many bugs in it!

Such as?

It doesn’t alter the program much. CRUNCH 15 will get rid of (most) spaces in a line, empty statements, empty lines, and REMs (except the first one).

Edit: Empty lines crossed out, needs CRUNCH 31 to remove those too…

And to use it every single branch of a progam would have to be re-tested

It shouldn’t mess with your program’s flow…

An interesting problem.

Indeed, though to my mind there would need to be some sort of guard data and/or sanity checking to prevent from either the data format changing in a live setup (or a one-off “update” phase) but most importantly to try to mitigate the risk where the data itself is bad. Imagine the fun that could occur if the server restarts (maybe in an error catch that CHAINs itself) which accesses the bad data which causes the thing to crash which restarts it so it can access the bad data which…you see where this is going? ;-)

Edit: I can think of ways to avoid this.

Piece of cake. You don’t need a system variable. Dynamic Areas can be named. So when the program starts it should enumerate all dynamic areas and if it finds one with such and such a name, then use it. Otherwise, create a new Dynamic Area and start from the beginning.

Mmmm… What happens if two instances of the server run in two TaskWindows…? ;-)

I probably should have re-phrased my point – It produces crunched code with too many bugs in it.

There may only be one bug in CRUNCH which manifests itself lots of times. Either way, it is not reliable with existing code.

It just does not do the job!

Now, that is really interesting. I have been running Basic$Crunched programs for a very long time and never found a bug to ascribe to it. I would love to have the details.

Dynamic Areas can be named.

Well, that is what I had in mind, but I did not want to elaborate and confuse the issue. ;-)

CRUNCH 15 will get rid of […] empty lines […]

Just for clarity’s sake, it does not do empty lines; those might be the target of GOTO etc.

Just for clarity’s sake, it does not do empty lines; those might be the target of GOTO etc.

Ah, you’re right. There’s five entries there. ;-)

>HELP CRUNCH
This command removes specified spaces from the current program.
CRUNCH <expression>. The bits in the number mean:
0: spaces before statements
1: spaces in statements
2: REM statements (except first)
3: empty statements
4: empty lines

It just does not do the job!

Now, that is really interesting.

I was expecting that response a little sooner, I presume you were busy :)
John clearly hadn’t read your earlier statements about how long you’d had the Basic$Crunch set in your boot sequence or hit a memory retention issue.

Like Steve D, I have run with Basic$Crunch set for many many years, and never had a problem caused by it. And I run and develop some significantly large programs!

It does cause me problems when the Set goes missing (eg after replacing Boot) and things run out of space!

Yes, I had noted Steve’s point.

I will have another look to see if the many errors produced can all be attributed to the same statement type in my uncrunched code.

OK – that did not take long. I was too hasty blaming CRUNCH for the errors.

Because I can not use CHAIN to auto-crunch my programs, I saved and edited a crunched version of the programs.

It is !Edit which destroys the crunched programs. I can not find any errors with CRUNCH (auto or manual).

I have found a way to achieve the chaining of one program to another without using CHAIN.

OSCLI (“Run !RunImage”) seems to behave the same as CHAIN “!RunImage”, but allows the new program to be auto-crunched.

It is !Edit which destroys the crunched programs.

As I quoted yesterday:

Note that CRUNCH %10 may make a program uneditable.

OSCLI (“Run !RunImage”)

That is aliased to *BASIC -quit !Runimage" so it will auto-crunch, and because it is called from the running program it does replace it in the wimp slot, possibly one of the few occasions that this is the desired effect. ;-)

Most of the apps I make public are compiled C. However, I do have two Basic apps which are ‘helper’ apps for some of my graph plotting apps. They are in Basic because they use EVAL to allow user entered functions to be evaluated ‘on the fly’. I received a report that one of them would not run in the wimp slot I had set in the !Run file, although the slot was fine on all my machines.

To cut the story short, this thread triggered me in to trawling through the various obey files run during my own boot process. There it was – on all my machines BASIC$Crunch was being set during boot.

Is it a polite thing to do, to actually ensure the sys$var is set in the !Run file of an application that is available to others?

Something that I do not see mentioned. Optimize the algorithm.

+1

Adding " for BASIC". There is no optimising compiler to help.

Is it a polite thing to do, to actually ensure the sys$var is set in the !Run file … ?

It is a question that has much concerned me, but I ended up making Basalt do it anyway. I think it is an intervention that has no downsides ¹, unless you want to save a program already in memory as John did. ;-)

I would much prefer an official change to BASIC.

¹ famous last words

I think it is an intervention that has no downsides 1, unless you want to save a program already in memory as John did. ;-)

Unset <Basic$Crunch> ?

@DavidS,

Thank you. I am already working on my HTTP Server program from the polling loop out.

To everyone else, Also Thank You. Your suggestions are making big improvements. CPU Load is now showing 0.0% for a lot of the time that was continuous heavy load aound 50%. (And Auto crunch is working well)