xsharp.eu

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

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, 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

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

Hi Wolfgang/Karl,

wriedmann wrote: your results are speaking for a very good implementation in the runtime.

I agree, hats of to teamX# again!

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

Count me, one of those "lazy coders" but I do not use ArrayNew(..), mostly ary := {} and AAdd.

...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

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.

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