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
Performance comparison X# runtime vs Vulcan runtime
Performance comparison X# runtime vs Vulcan runtime
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
- lumberjack
- Posts: 727
- Joined: Fri Sep 25, 2015 3:11 pm
- Location: South Africa
Performance comparison X# runtime vs Vulcan runtime
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
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
Johan Nel
Boshof, South Africa
Performance comparison X# runtime vs Vulcan runtime
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
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)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Performance comparison X# runtime vs Vulcan runtime
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
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
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
- lumberjack
- Posts: 727
- Joined: Fri Sep 25, 2015 3:11 pm
- Location: South Africa
Performance comparison X# runtime vs Vulcan runtime
Hi Wolfgang/Karl,
I agree, hats of to teamX# again!wriedmann wrote: your results are speaking for a very good implementation in the runtime.
______________________
Johan Nel
Boshof, South Africa
Johan Nel
Boshof, South Africa
Performance comparison X# runtime vs Vulcan runtime
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.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!
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
XSharp Development Team
chris(at)xsharp.eu
Performance comparison X# runtime vs Vulcan runtime
Count me, one of those "lazy coders" but I do not use ArrayNew(..), mostly ary := {} and AAdd.
-
- Posts: 97
- Joined: Tue Mar 01, 2016 11:50 am
- Location: Germany
Performance comparison X# runtime vs Vulcan runtime
...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
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
Performance comparison X# runtime vs Vulcan runtime
Hi Gerhard,
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.
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.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.
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
XSharp Development Team
chris(at)xsharp.eu
Performance comparison X# runtime vs Vulcan runtime
Hello Johan,
Seems a good way to me, even AAdd is poor regarding performance.
What would the non lazy programmer do?
Dick
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.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...
Seems a good way to me, even AAdd is poor regarding performance.
What would the non lazy programmer do?
Dick