VB had certain constructs and keywords that would tax the hell out of the host computers resources. Constructs such as while,wend loops were to be avoided where possible. Where VB was actually faster at some maths and graphics operations than C++, it did quite poorly at other mainstream operations. Does Xojo have any constructs and keywords that one should avoid using. I know that this is like asking for the length of a piece of string, but I was curious to hear what obvious programming methodology should be avoided even with Xojos brisk performance on a Mac.
DoEvents - pure evil
Agreed, its like the handbrake of the coding world.
Are DoEvents ok in console and web projects?
Iterating over files in a FolderItem should be done by storing Count in a local variable and going from 1 to count. Getting the count of items in a directory is expensive and iterating in any other order than linearly forwards will give you a massive performance degradation.
DoEvents is okay in console. For web, the main loop already does it for you.
Don’t use CountFields and NthField In a loop or even repeatedly. Don’t use Len and Mid to iterate over a string either. Break the string into an array using Split and access each element instead.
Creating and destroying objects is expensive. Reuse objects where you can, or avoid destroying them until you must.
indeed, we have a plugins which creates thousands objects per second and destroys them right away.
In that case having code to recycle them was a great improvement. We simply store them in an array and later when we need a new one, pick one from array and fill it with values.
Don’t concatenate a lot of strings together into a long string… Put them in an array and use Join.
LOOPING
As a longtime VB user, I was quite happy about looping operations, when I benchmarked them it was very similar to C/C++. I would say LOOPING is something to keep in mind in Xojo, just the reverse of what the OP said.
In two ways: one, make sure that your expression after TO is simple, like a single variable, since it is calculated each iteration, whereas it is not in VB. This is a speed issue but also a code/bug issue. The other thing is that even if you do this, looping in Xojo is still a bit slow. When I need speed in looping operations, I write it in C/C++ and put it in my library that my Xojo app calls. I get a 100% speed improvement that way.
UPDATING THE UI
Xojo tends to be more serial than VB, and this comes out in UI updating quite often. Now, VB is thread-safe, whereas Xojo isn’t, but I’m not just talking about updating within a thread. If you do [Control].Refresh in VB, it is much more likely to update the UI right away, whereas Xojo might wait a bit, most likely when the routine [chain] ends. With Xojo you are, threads or no, you are more likely to use Timers to update the UI. (BTW, DoEvents is evil, and this is where many a Xojo coder goes to the dark side - we want an easier way to update the UI in a snappier fashion. Xojo isn’t lacking in this regard, you just have to think of things differently. (And remember VB only has to deal with Windows.)
[quote=97443:@Garth Hjelte]In two ways: one, make sure that your expression after TO is simple, like a single variable, since it is calculated each iteration, whereas it is not in VB. This is a speed issue but also a code/bug issue. The other thing is that even if you do this, looping in Xojo is still a bit slow. When I need speed in looping operations, I write it in C/C++ and put it in my library that my Xojo app calls. I get a 100% speed improvement that way.
[/quote]
Because Xojo yields on loop iterations, when you need speed use #pragma DisableBackgroundTasks
Thanks Karen, perhaps I need to revisit this (rebenchmark). However, to mix the concerns, that #pragma is routine wide, so if you have a direct UI Update (non-thread) it’s REALLY not going to occur until the routine is out of scope, and that frankly sucks. But with VB that’s not a concern at all.
(I’ve been doing REAL/Xojo for a long time and it’s probably that I have preconceived notions that perhaps have faulty premises (back when I wasn’t completely aware).)
Back to the OP’s concern, on the positive Xojo works so much easier when you work WITH Xojo in these regards. So his question is really a very good one. Xojo doesn’t have to be like VB, and although I think its unarguable that VB does more for you, Xojo has several vital elegant solutions that put it in a “class” (pardon the pun) all its own. I did give up VB for Xojo and I don’t forget that fact.
I cant remember if the following is an issue in Xojo or if it was VB (the memory is going!!). But in one of them I am sure the ubound was computed every time you go round the loop and with a large array it slows things down.
for lp = 0 to ubound(myArray)This was tested on the NUG and it turns out that any slowdown is so minute as to be insignificant.
[quote=97500:@Nathan Wright]I cant remember if the following is an issue in Xojo or if it was VB (the memory is going!!). But in one of them I am sure the ubound was computed every time you go round the loop and with a large array it slows things down.
for lp = 0 to ubound(myArray)FYI… in SWIFT they warn you (in the manual) about exactly this… it re-evaluates the loop end value each time. The manual suggests placing it in a temp variable to use in the FOR statement
[quote=97446:@Karen Atkocius]Because Xojo yields on loop iterations, when you need speed use #pragma DisableBackgroundTasks
[/quote]
To see if the loop evaluates the end value at each loop, I tried to have a timer change the end value during a loop to stop it.
It does not seem to yield so the timer never fires until the loop is over.
As a matter of fact, on a very long loop, Xojo freezes just as bad as during While/Wend.
That is on Mac. Windows may be different.
Putting aside the caching behvaior (UBound() is possible to change, thus affecting the loop amount), so you are saying the UBound() call even on slow computers is so fast it makes it inconsequential?
I wouldn’t as a matter of practice change the size of the array in the loop. But if I do I then loop backwards.
It’s been a few years but I had this exact same discussion with Aaron Ballman (who was the compiler guy at the time). Think of it as a property lookup rather than a recalculation. Whether it returns 1, -1, or 1,000,000 doesn’t matter - it’s still an integer. I did several different tests on this and the difference was just a couple of microseconds even on loops of millions. What goes on inside the loop was more important than getting the array upper bound.