Performance comparison X# runtime vs Vulcan runtime

This forum is meant for questions and discussions about the X# language and tools
User avatar
wriedmann
Posts: 3753
Joined: Mon Nov 02, 2015 5:07 pm
Location: Italy

Performance comparison X# runtime vs Vulcan runtime

Post by wriedmann »

Hi Johan,

I know that AAdd() is slow, but I have used it to stress the runtime a bit.

In normal application code I would never use such code - I would write as suggested by you.

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
User avatar
lumberjack
Posts: 726
Joined: Fri Sep 25, 2015 3:11 pm
Location: South Africa

Performance comparison X# runtime vs Vulcan runtime

Post by lumberjack »

Hi Wolfgang,

Was just mentioning it since using AAdd() in both instances or ArrayNew(), will show the performance penalty to the "lazy" programmers out there...

Johan
______________________
Johan Nel
Boshof, South Africa
FFF
Posts: 1577
Joined: Fri Sep 25, 2015 4:52 pm
Location: Germany

Performance comparison X# runtime vs Vulcan runtime

Post by FFF »

Johan, Wolfgang,
copied J's code to the same app i made for W's. Renamed func and let them run one after another.
Result for W: 2,29s,
for Johan 2,32 (!)
Then swapped the calls getting 2,28 and 2,33
Killed Xide, restarted, compile and swap again, result similiar.
=> "lazy ones" don't get punished as much as they used to be ;)

@all: i'd suggest at least for small test apps, to post always a complete export file.

Karl
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
User avatar
wriedmann
Posts: 3753
Joined: Mon Nov 02, 2015 5:07 pm
Location: Italy

Performance comparison X# runtime vs Vulcan runtime

Post by wriedmann »

Hi Karl,

you results are speaking for a very good inplementation in the runtime.

Sincerely, I use much more AAdd() calls than ArrayNew() class - simply because most of the time at the start of the loop I don't know the number of elements the array will have at the end.

Wolfgang

P.S. will do that with the sample applications the next time I have one
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
User avatar
lumberjack
Posts: 726
Joined: Fri Sep 25, 2015 3:11 pm
Location: South Africa

Performance comparison X# runtime vs Vulcan runtime

Post by lumberjack »

Hi Wolfgang/Karl,
wriedmann wrote: your results are speaking for a very good implementation in the runtime.
I agree, hats of to teamX# again!
______________________
Johan Nel
Boshof, South Africa
User avatar
Chris
Posts: 4871
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Performance comparison X# runtime vs Vulcan runtime

Post by Chris »

FFF wrote: @Chris: there's a trap in XIDE: created a new X# core sample, added the x#runtime references, (Core&VO). Platform auto-changed to x86. clicking on anyCpu (or x64) works, compiles and runs, but silently switches back to x86!
Thanks Karl, will fix this. It's only a UI thing, when you select Vulcan/VO dialects, x86 gets also selected, because that is necessary when using the vulcan dll files which are all x86 only.

You can actually change the platform to AnyCPU manually and it will be used from now, will just reset in the UI, next time you go to the app properties.

Chris
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
User avatar
rjpajaron
Posts: 364
Joined: Fri Nov 06, 2015 12:01 am

Performance comparison X# runtime vs Vulcan runtime

Post by rjpajaron »

Count me, one of those "lazy coders" but I do not use ArrayNew(..), mostly ary := {} and AAdd.
g.bunzel@domonet.de
Posts: 97
Joined: Tue Mar 01, 2016 11:50 am
Location: Germany

Performance comparison X# runtime vs Vulcan runtime

Post by g.bunzel@domonet.de »

...maybe offtopic - but some performace infos out of this article:
https://www.codeproject.com/Articles/15 ... #perftests


I did a lot of performance tuning with a profiler and here are my results:
•Always use a StringBuilder and never strings concats.
•Never do the following stringbuilder.append("string1 + "string2") because it kills performance, replace it with two stringbuilder appends. This point blew my mind and was 50% faster in my tests with the profiler.
•Never give the stringbuilder a capacity value to start with e.g. var stringbuilder = new StringBuilder(4096); . Strange but it is faster without it.
•I tried replacing the StringBuiler with a MemoryStream but it was too slow (100% slower).
•The simplest and the most direct way is probably the fastest as well, case in point reading values as opposed to lexer parser implementations.
•Always use cached reflection properties on objects.


HTH

Gerhard Bunzel
User avatar
Chris
Posts: 4871
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Performance comparison X# runtime vs Vulcan runtime

Post by Chris »

Hi Gerhard,
g.bunzel@domonet.de wrote: •Never give the stringbuilder a capacity value to start with e.g. var stringbuilder = new StringBuilder(4096); . Strange but it is faster without it.
That should depend on the details. If you are creating lots of StringBuilders and most of them end up being just a few characters long, then StringBuilder{4096} (setting Capacity to 4096) will be overkill, it will be using too much (wasted) memory and will be also slower. But if you know that a certain StringBuilder will end up having around 4000 characters, then using StringBuilder{4096} should be much faster than using a simple StringBuilder{}. And the difference would be a lot larger for longer sting(builder)s.

What StringBuilder{4096} does, is to pre-allocate memory for 4096 characters, so it will not need to allocate more and more memory while the StringBuilder increases in size (but remains smaller than the specified length). Otherwise, it allocates memory for just 16 characters (the default Capacity), and if it actually reaches that size, next time you add a character, it allocates now memory for 32 characters in a new buffer, copies the old data from the old buffer to the new one and releases the previous memory buffer. Same when you reach 32 characters, in allocates another buffer for 64 characters, copies over the data again etc.

So, in general, it is much more efficient (regarding speed and memory consumption/strain to the garbage collector) specifying an initial Capacity, but only if you know in advance how long your StringBuilder will end up. Always setting up Capacity to a large number even for very small StringBuilders, will indeed hurt performance.

Btw, the same applies to ArrayLists, List<>s and almost every other standard .Net collection.
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
ic2
Posts: 1856
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

Performance comparison X# runtime vs Vulcan runtime

Post by ic2 »

Hello Johan,
lumberjack wrote:
Was just mentioning it since using AAdd() in both instances or ArrayNew(), will show the performance penalty to the "lazy" programmers out there...
I'm catching up forum messages and I was intrigued by this remark. I have many places in my program where I use AAdd. E.g. we want a total of a series of general ledger accounts and for every record with a booking on a GL, we use AScan to see if we already added that GL in an array, if not, we AAdd to the GL array and the total value array.

Seems a good way to me, even AAdd is poor regarding performance.

What would the non lazy programmer do?

Dick
Post Reply