Basic For Loop speed test between C#, VB.Net and B4J

[Peter Simpson]

Good morning fellow B4X'ers,
So I've got to start a new project for a new client in the next few weeks, but the client specifically requested that the project be developed using #C, the answer is yes I can do that if need be.

I would personally prefer to use B4J for this project as VS DataGridViews are nowhere near as light weight as they should be in my opinion and also not as fast either. I personally find that DataGridViews do not initially populate nearly as smoothly as B4X xCLV with my modified lazy loading routine which loads 1000 results at a time, but the client is insisting on C# so sadly that's what they will get.

An hour ago I decided to create 3 simple For Loop test programs just to see just how quickly C#, VB.Net and B4J can run a counter in a label counting from 0 to 100000. B4J is using Sleep(0) whilst both C# and VB.Net are using Application.DoEvents() to keep the programs responsive. Yes I know I could have used async with await instead, but I didn't.

PLEASE NOTE: The counter speed is processor dependent, this was created on my spare laptop.


Enjoy...

 

[OliverA]

Something missing? Either on my end or on your end...

 

[jimmyF]

Wow!

 

[KMatle]

In 15 secs I create a db with B4x with 100K entries Nah. Just kidding. It's 20

 

[Erel]

An hour ago I decided to create 3 simple For Loop test programs just to see just how quickly C#, VB.Net and B4J can run a counter in a label counting from 0 to 100000. B4J is using Sleep(0) whilst both C# and VB.Net are using Application.DoEvents() to keep the programs responsive. Yes I know I could have used async with await instead, but I didn't.

This benchmark is not very meaningful. While Sleep is sometimes considered an alternative to DoEvents they are based on completely different algorithms.

 

[sorex]

I guess the big difference is that DoEvents updates the entire UI (window, button, label, taskbar button if any) and not only the label.

 

[Erel]

guess the big difference is that DoEvents updates the entire UI (window, button, label, taskbar button if any) and not only the label.

Actually no. Calling Sleep(0) will also update everything.

 

[Erel]

DoEvents - traverses the message loop.
Wait For / Sleep - Stores the current sub state and returns, letting the message queue to be handled properly. Later the sub will be resumed based on an event or internal timer.

DoEvents is unstable and unreliable as not all messages can be handled like this. The issues become more problematic when there are multiple calls to DoEvents. In such cases it becomes unmanageable as the DoEvents can be nested and in unexpected ways.

Agraham's explanation about resumable subs: B4J Tutorial - [B4X] How Resumable Subs work | B4X Community - Android, iOS, desktop, server and IoT programming tools

 

[Peter Simpson]

This benchmark is not very meaningful. While Sleep is sometimes considered an alternative to DoEvents they are based on completely different algorithms.

You are 100% correct, this was just a quick test as I wanted to see which IDE would complete a simple task first with a basic For Loop with a label being updated.

Without using Application.DoEvents in VS and Sleep(0) in B4J the .jar file completed both the 0-100000 and the 0-1000000 counter tests faster than the .exe files managed to do so. The CPU usage is around 2% less for the .jar file compared to the .exe files. The .exe files startup much faster than the .jar file from double clicking on their icons. From memory the .jar file was about 370 KB in size, the VB.Net .exe was about 19 KB in size and the C# .exe file was about 14 KB. Obviously all runtime C++ redistribution files etc etc etc are already installed on my test laptop.

I created the comparison because I wanted to know which was faster performing the extremely simple task of populating and updating a label whilst using a basic For Loop, nothing special really. The simple task of using a basic For Loop was the simplest thing I could think of which would take a couple of minutes per IDE to create. The sleep in B4J and the doevents in VS (doevents could have been replaced with label2.update in VS) was only used so that I could visually see the labels being updated. Using label2.update the program would freeze until the task was completed, but using label2.update the task would finish about 2 seconds faster, still nowhere near as fast as the .jar example.

As I mentioned previously without the sleep/doevents in ide, the JavaFX .jar file (on my test laptop) finished the 0-1000000 counter test quicker than the .exe versions. That was a complete surprise to me, can you imaging if that was a more complicated task and not just one silly little label.

On a few occasions both the VB.NET and the C# files actually finished on identical times, maybe I should have used C++ instead of C#.

With or without the sleep/doevents the results are still the same, the .jar file always finishes this extremely simple task faster, and that's not meaningless.

Cheers...

 

[sorex]

a while ago I ported a data generator routine made in B4J to VS2019 just to see if it would be faster as it took ages.

to my surprise nothing worth mentioning was gained or it was even slower on a routine that needed hours/days.

as sysadmin you work with a lot of monitoring/config tools and a lot of them are still java products and pretty solid too.

F-Secure Policy Manager
Ubiquti/Unifi management server
Alcatel PBX config (shite tool tho )

to name a few.

boot up times are partial cheats when using MS compiled binaries. They heavily depends on stuff that's already running in the background of windows (.NET/DLLs)
that's why they always claimed that IE was the fastest starting browser around (it was already half loaded by the system)

 

[Sandman]

Edit: And now it works for me. Who knows, perhaps an intern at YouTube tripped a NAS network cable just as I tried to watch.

 

[Peter Simpson]

View attachment 83035

Hmm., I dunno...

 

[Erel]

Works fine here.

 

[LucaMs]

Try (VB.Net) using Label1.Refresh instead of DoEvents; I get about 26 seconds (still too much).

I would personally prefer to use B4J for this project as VS DataGridViews are nowhere near as light weight as they should be in my opinion and also not as fast either.

I hope that soon we will have b4j controls like that.

 

[Douglas Farias]

I was curious about Python....

 

[Peter Simpson]

I was curious about Python....

Maybe B4X user @wonder can answer that particular question for us all. Bruno appears to be the resident Python export on the community and I personally didn't install Python onto my development laptop when I was installing VS.

I'm not really interested in Python, as it's yet another language to learn as if things were not difficult already with VB.Net, C, C++, C#, F#, PHP, Java, JavaScript blah blah blah

 

[Douglas Farias]

Maybe B4X user @wonder can answer that particular question for us all. Bruno appears to be the resident Python export on the community and I personally didn't install Python onto my development laptop when I was installing VS.

I'm not really interested in Python, as it's yet another language to learn as if things were not difficult already with VB.Net, C, C++, C#, F#, PHP, Java, JavaScript blah blah blah

 

[MarkusR]

counting to 100000 in 15 seconds or 50 seconds is questionable because of unnecessary redraws.
i will make a c# test ...

 

[LucaMs]

counting to 100000 in 15 seconds or 50 seconds is questionable because of unnecessary redraws.

Without "redraws" (labels) I got 306ms with b4j, 11ms with vb.net.

 

[Peter Simpson]

counting to 100000 in 15 seconds or 50 seconds is questionable because of unnecessary redraws.
i will make a c# test ...

Okay that's fine by me, please try it out for yourself and let me now your findings.

The redraws are irrelevant, as are the labels and the button. The labels were only there for my own personal gratification as was the button, even without the labels and button, the .jar file creamed the .exe files counting to 1000000, that's all I have to say on the matter.

Did you read where I said PLEASE NOTE:
Please consider processor types, cores count, processor architecture, speed, mobile vs desktop blah blah blah. The three files were created on my i7 8th Gen on my laptop, the files were recorded on my i5 6th Gen laptop (which was slower than my i7) which already has the Screen Recorder Pro software installed on it, I also have a brand new i9 ESports gaming system, I'm sure if I were to test the three files on my i9 the test would be over in well under 10 seconds, if not under 5.

I hope that you can see where I'm coming from...