Others commented similarly on various threads: I find that in many cases, application design does much more for the user perception of speed than any code optimization.
Now, if you have some processing intensive routines, and until LLVM arrives, you may consider offloading some of the processing intensive stuff to DLL’s written in PowerBASIC (a descendant of Turbo BASIC). PowerBASIC spent a lot of time and effort optimizing their compiler to be as fast as can be. I’ve used that strategy on some occasions with my VB6 applications that needed a performance boost, where I could not change the design. Of course, this is only good on Windows, PowerBASIC does not exist on other platforms. PB has not issued any updates to their product in a while, but they still are in business. I have tested some of my old DLL’s with Xojo. It works. But I have not had to resort to this approach with any of my XOJO applications yet.
Private Sub Form_click()
Dim x As Double
Dim y As Double
Dim i As Long
Dim t As Single
x = 1
y = 1.000001
t = Timer
For i = 1 To 100000000
x = x * y
Next
t = Timer - t
Print " X= "; x
Print " Temps d'execution :", Round(t, 2) & " Sec"
End Sub
Back in 2005 when I needed fast code to calculate CRC32 on files to prove integrity. See this VB6 class . It’s ultra fast. Think this approach would also work in Xojo.
Lookup tables (like the one in your InitCRC32 subroutine) are always a great way to get speed gains.
I remember using lookup tables for sin and cos operations when dabbling with 3D programming in assembler, prior to math co-processors, where each CPU cycle was worth gold.
I got mine in 1991 and thought it was the most brilliant piece of software EVER. I had just convinced my parents to buy me a 486DX computer with windows 3.0 which put me light speeds ahead of everyone including NASA who I think were using 286s at the time.
uh dont say Win3 @ i80386 DX was fast… for a long time I used Geoworks Ensemble… the UI and native Apps were way faster than everything on Windows… even on 286er with real mode… but well this might be offtopic…
[quote=114507:@Alwyn Bester]Lookup tables (like the one in your InitCRC32 subroutine) are always a great way to get speed gains.
I remember using lookup tables for sin and cos operations when dabbling with 3D programming in assembler, prior to math co-processors, where each CPU cycle was worth gold.[/quote]
Not just 3d, any trig related graphics, even drawing a circle! Mind you, I’m going back to 1979-80…
According to Bernard Vergnes who directed Microsoft France and later became director of Microsoft Europe, the people who had developed Ensemble, where bought out by Microsoft to optimize Windows. That was back in the Windows 3.2 era. I am not sure Windows 95 was racing afterwards, though
On the subject of VB6 being faster than Xojo, the benchmark has spoken, and looking at the code I cannot find any difference that would justify the faster VB6 other than a code that runs faster the specific operations used in the test.
But to me this is only one criterion in a choice between the two development environments.
VB6 got no support from Microsoft since the advent of .NET
Xojo gets an attentive suport with engineers attending this forum, and an outstanding support from a competent and (mostly) friendly community of programmers.
Xojo is cross platform. If no platform specific code like declares is used, you can generate a Macintosh or Linux app at the flip of a switch.
That maybe a question of personal preference, but I find the LR absolutely brilliant. I never had such a great resource when I was using VB, with ready to apply examples.
Somehow, I like better the management of events handlers in Xojo. You choose from a list instead of having to research the names.
Sure, for Windows only, and when one is accustomed to VB, Xojo advantages maybe debatable. But I think it is probably better to go with a supported product than with one that has effectively been dropped by its publisher.
Xojo has not said its last word. There are actually two compilers that can execute the benchmark code. The regular one used by the IDE, and the LLVM compiler used for the XojoScript class.
I used the very same code as posted by Djamel in a XojoScript control source, except I used PRINT in the last line like so
[code]#pragma BackgroundTasks False
Dim x As double
Dim y As Double
Dim i As int32
Dim t As double
And placed msgbox msg in the Print event of XojoScript1.
On my now old PC, a built app gives :
Regular code : 0.94 s.
XojoScript : 0.48 s
It is already way below 0.66 s. If I apply the same ratio to Djamel benchmark, which is probably the time he would get from the same code on his machine, that would give a whopping 0.35 s. Almost half VB6 time
For these kinds of mathematical operations, at least, and within the limits of the exercise, XojoScript could be a good tip to accelerate code.
Very nice, it’s good news, on my PC , core Intel i7 @ 3.5 Ghz , Borland C/C++ compiled in C, gives 0.336 Sec.
Xojo gives 0.7, with this logic, Xojo regular code must give around 0.35 sec, it is not so far than Borland C !
[quote=114754:@Djamel AIT AMRANE]Very nice, it’s good news, on my PC , core Intel i7 @ 3.5 Ghz , Borland C/C++ compiled in C, gives 0.336 Sec.
Xojo gives 0.7, with this logic, Xojo regular code must give around 0.35 sec, it is not so far than Borland C ![/quote]
Actually, VB6 maybe a great chance for Xojo. VB . NET has a way to alienate VB6 users, who probably appreciate Xojo as a valid cross platform replacement