QLCommander v2.2.x

[tofro]

<>
I decided to compile QLCommander with Turbo because
- Turbo it is said to be slightly faster

Anyone choosing to work with original QL hardware will have the patience to forego the 5-10% Turbo speed up

- the discussions about "Q_Liberator malaise" and Q60

As Ive demonstrated elsewhere, for those platforms where this matters, they should just run the SBASIC source code directly. The outcome is virtually identical qua speed, functionality, compactness, etc. And for those who so choose, their code can be obfuscated, producing a result not much worse than decompiled Turboed or Qlibbed stuff.

- and last but not least, I had Martyns support on all Turbo quirks

Yes, that must be invaluable Martyn is welcome to compile any of my programs, especially those that might conceivably benefit!

I have tried with some of them, but without much success. It took me an hour just to Turbo compile that simple 80 line DirSize program, above. Of course, had I been familiar with Turbo, and written programs from scratch with Turbo in mind it might not be too hard..

I dont mean to dis Turbo. I used it for many years, from SuperCharge and onwards. But it just like having a girlfriend who insists on everything being done her way, and always trying to "improve" you. And at the end of the day the sex is not that much better..

Well, to set things right, Turbo, on average, speeds up programs closer to 100% than 10%, in my experience. This can be the difference between a program "that works" and one that doesn't, especially on non-SMSQE machines.
And yes, it's not quite as easy to make friends with compared to QLib. Once you know its quirks, it's quite easy, however.
OTOH, QLib is (IMHO) totally useless for SBasic (at least with regards to possible performance gains. SBASIC is 100% equal in speed compared to QLibbed programs on my machines). You'd better go with providing your source code, as you say.

[pjw]

<>
Well, to set things right, Turbo, on average, speeds up programs closer to 100% than 10%, in my experience. This can be the difference between a program "that works" and one that doesn't, especially on non-SMSQE machines.
<>

Compared to what? There is no hard and fast formula. It all depends on the application. A user interface doesnt necessarily benefit from a speed up, while speed critical stuff can be done in toolkits in assembler. My estimate (which was just a wild guess; yours may well be nearer the mark) was based on comparing Qlib-compiled on Qdos as opposed to Turbo-compiled.

And I know Im not supposed to mention it, but with a simple change of platform any difference pales into insignificance..

[tofro]

<>
Well, to set things right, Turbo, on average, speeds up programs closer to 100% than 10%, in my experience. This can be the difference between a program "that works" and one that doesn't, especially on non-SMSQE machines.
<>

Compared to what? There is no hard and fast formula. It all depends on the application. A user interface doesnt necessarily benefit from a speed up, while speed critical stuff can be done in toolkits in assembler. My estimate (which was just a wild guess; yours may well be nearer the mark) was based on comparing Qlib-compiled on Qdos as opposed to Turbo-compiled.

And I know Im not supposed to mention it, but with a simple change of platform any difference pales into insignificance..

According to Tim: You got your supermodel, I've got mine

[pjw]

<>
Well, to set things right, Turbo, on average, speeds up programs closer to 100% than 10%, in my experience. This can be the difference between a program "that works" and one that doesn't, especially on non-SMSQE machines.
<>

Compared to what? There is no hard and fast formula. It all depends on the application. A user interface doesnt necessarily benefit from a speed up, while speed critical stuff can be done in toolkits in assembler. My estimate (which was just a wild guess; yours may well be nearer the mark) was based on comparing Qlib-compiled on Qdos as opposed to Turbo-compiled.

And I know Im not supposed to mention it, but with a simple change of platform any difference pales into insignificance..

According to Tim: You got your supermodel, I've got mine

Well, if you like a bit of BDSM rough and tumble, youre welcome to her. For my part I like the more compliant, understanding type.

I am, however, willing to try new things. I just dont think Turbo was made for EasyPointer. I gave it up long ago for that reason, and although George has done commendable work on it, you dont see a lot of Turbo compiled PE programs around, do you? His TPTR is still a mystery to me. Perhaps when I retire I'll have time to take a closer look. Oh wait: I AM retired! Ok, maybe next life, then..

[tofro]

I am, however, willing to try new things. I just dont think Turbo was made for EasyPointer. I gave it up long ago for that reason, and although George has done commendable work on it, you dont see a lot of Turbo compiled PE programs around, do you? His TPTR is still a mystery to me. Perhaps when I retire I'll have time to take a closer look. Oh wait: I AM retired! Ok, maybe next life, then..

Well, I've written some. QJewels, for example is Turbo-compiled and based on EasyPtr. Wasn't that hard. And the whipping was gentle.

[pjw]

I am, however, willing to try new things. I just dont think Turbo was made for EasyPointer. I gave it up long ago for that reason, and although George has done commendable work on it, you dont see a lot of Turbo compiled PE programs around, do you? His TPTR is still a mystery to me. Perhaps when I retire I'll have time to take a closer look. Oh wait: I AM retired! Ok, maybe next life, then..

Well, I've written some. QJewels, for example is Turbo-compiled and based on EasyPtr. Wasn't that hard.

Ok. Good one. I hadnt realised. But why Turbo for that? Speed is not of the essence in that context..

I realise we are a minority here. Four people downloaded my previous example comparing Q_Liberator with Turbo, yet here comes another:

DirSize2.zip

(10.02 KiB) Downloaded 3 times

I compiled the program with Qlib, and then after some faffing around managed to compile a slightly modified version of the same simple program with Turbo. This time Ive added some Turbo compiler directives, although I dont know if the program could be optimised further..

I then tested them for speed. The results are in the included text file. Id say the program is pretty typical. It takes potentially massive amounts of data that needs to be processed quickly. Turbo was certainly not 100% faster. More like 20%-30%. How many people using actual QL-like hardware are going to bother whether something takes 31 seconds or 25? If speed is imporant use an emulator and do the same in < 1 second! I rest my case.

And the whipping was gentle.

Oh thats really too cruel! Evil! You should try to get your money back!

[tofro]

Ok. Good one. I hadnt realised. But why Turbo for that? Speed is not of the essence in that context..

Just for the pain

Jokes aside, no. I just wanted to find out if it's possible after George Gwilt's claims and his article in QL Toady. And it was. Very well possible, indeed. And yes, indeed there is the need for speed: On the interpreter (or QLiberated) QJewels' animations are painfully slow on a QXL, almost unplayable. Turbo-compiled, it's halfway acceptable (That was the exact experience that made me write "can make a difference between a program that works..." above.

I would admit that if you want to compile an existing PE program with Turbo, you'd have to spend quite a bit of effort to find the places where Turbo's quirks might hurt you. If you start from scratch, however, it is quite easy to write programs that work just as well under the interpreter and Turbo. I'd say it really is a matter of taste.

[tofro]

What I did first, was introduce a call counter in your code (i.e. count recursive calls of CalcDirSize). With your original code and your set data space of 96k, it managed to reach like 380 calls before running out of data space.
Then I made the following changes to your code:

Code: Select all

REMark Line 8700 removed (b$ = MDHEADR$(newname$)
REMark Line 8800 removed (x = LONGINTEGER (b$(1 TO 4)))
8810 x = FLEN (\fname$) : REMark added, should do basically the same as the above

(I think that should do roughly the same as your code)
And the code could happily do 900 calls and more with the same data space size set as above (and ran through even my longest directory trees with no problem whatsoever).

Thank you Tobias - the counter is a great idea! Also the use of flen(\name$)!! How could I forget about flen? I am using it in other parts of my program!
WIth flen and dataspace 64k the test program happily does at least 1629 calls without any issues! (The largest win drive I have "only" has 1629 directories)

Next step, after Per updates the toolkit, is to check which is faster: MDHeader or flen

Just one further comment:

LOCals are fine and keep your program tidy. Until they aren't:

In your PROCedure, you have defined a number of pretty long LOCal strings. These make up roughly 300 bytes. Be aware the program has to allocate LOCal strings for every recursion, that is, every recursive call to your PROCedure will allocate ~300 bytes more data space which can only be released when the PROCedure returns from its inner calls. You are not using these strings after the recursion returns, so there is really no need for them to be LOCal. I would make them global strings (nothing wrong with global variables) and save quite a bit of memory. When you know a PROCEDURE or FuNction is called recursively, you really need to keep an eye out for the size of your LOCals and only make those LOCal that need to be - The ones that need to be separate for every recursive call.