Stefan Glienke

It probably is lacking the `()` there which it sometimes needs when invoking a method that returns an invokable type.

It basically does what "Run" does.

There is the IDE plugin that listens on the TCP port(range) specified in its settings and the client that is compiled into the test projects sends its result to it. What exactly should not work about that on any platform that can do TCP/IP?

What are you talking about?

Run it under the debugger so see where it's stuck?

https://bitbucket.org/sglienke/testinsight/wiki/Home On mobile you need a bare UI application though iirc - just make a form with a button that calls RunRegisteredTests. Either hardcode the uri to your developer machine or deploy the TestInsightSettings.ini that gets written next to the binary.

That's exactly what TestInsight does...

Seems to be written in 10.3 where TStringDynArray is declared as TArray<string> whereas before it was a dedicated array of string. My suggestion is to not use the dynamic array types from System.Types anywhere and wherever you work with any RTL functions that use them, hardcast in order to be compatible to <10.3.

GitKraken is not free for commercial use though. I like using SourceTree (after the 2.x disaster in 3.x it's usable again).

speed, min/max memory footprint, fragmentation, single/multi thread, sharing memory across threads?

There clearly is a race condition somewhere in the SeaMM.dll - either it works, or it raises AVs until it stackoverflows or it gets stuck inside a loop (keep clicking Start/Stop if it does not raise AV/SO) with these instructions: 00007FF9B59FB520 664103D0 add dx,r8w 00007FF9B59FB524 488BD9 mov rbx,rcx 00007FF9B59FB527 66895774 mov [rdi+$74],dx 00007FF9B59FB52B 488B01 mov rax,[rcx] 00007FF9B59FB52E 488BC8 mov rcx,rax 00007FF9B59FB531 4883C801 or rax,$01 00007FF9B59FB535 4883F801 cmp rax,$01 00007FF9B59FB539 75E5 jnz $00007ff9b59fb520 Anyway as you seem to be the author/modifier of that code you should be able to debug that yourself. As soon as I put a breakpoint I could not get the AV - which confirms my guess about the race condition.

Try removing the inline from function TIocpCrossSocket._NewIoData: PPerIoData; - possible that it trips over something there - apart from that I don't see how this could be related to anonymous methods. The variable assigned to is a local variable of a regular method and there are no anonymous methods in procedure TIocpCrossSocket._NewAccept(AListen: ICrossListen); that could change the location of that variable to somewhere else than the stack. Possible that the TBB code is sensitive to some garbage value in a volatile register that it does not properly check for.

From looking at the callstack I am pretty sure there is a defect it's in your code namely in TIocpCrossSocket._NewAccept or the code that calls this method in case of AListen being nil.

Been there, done that. And one day the enum gets its 33. element and stuff subtly starts failing 😉

The approach to store Min and Max Value for sets does not work as sets in Delphi can be max size of 32 Byte (set of Byte) - good luck storing that in an Integer. The core idea though is nice - I think I have also done this before: use a generic type as storage for type related values.

Technically in Delphi strings are only mutable if they have a ref-count of 1, otherwise a copy happens. And while it might be convenient to the average developer if you actually look under the hood how much instructions and implicit heap allocations happen if you are not paying attention and naively work with strings you will be scared.

- the december patch does not mention anything about IDE stability fixes - IDE FixPack is not yet released and only alpha state (and even may cause issues - well more precisely the CompilerFixPack for 64bit windows does - see https://quality.embarcadero.com/browse/RSP-23405) - DDevExtensions does not fix IDE stability issues but adds productivity features I am only using 10.3 for toying and it more often crashes (well the compiler gets into some state where it produces nothing than some internal errors after it eventually brings down the IDE) - and yes I am using the IDEFixPack alpha because I am not producing any production software with it.

https://stackoverflow.com/questions/22397861/why-is-string-immutable-in-java https://stackoverflow.com/questions/2365272/why-net-string-is-immutable

As I mentioned before the jump optimization highly depends on the CPU - and of course it only affects methods that are being called and not inlined. When inlined you have a jump no matter what. Only when being called it can benefit from two returns in each branch to avoid the jump over. Edit: Clarification - when inlined, putting the raise first is better because it only needs one conditional jump instruction (jump over raise call or not), taken in the common case. When putting it below it still has the conditional jump which is not taken in the common case but has a jump over this code in all cases when the common path is being used. What I would do regardless is to put the exception raising code into a non inlined subroutine to reduce generated binary code because then the code being jumped over is just a call (5bytes on 32bit). Another optimization is to make use of {$POINTERMATH ON} for your pointer type because then you can write: Target := @FData; Target[FCount] := AItem; And another neat trick to check if an Integer index is in range that only uses one compare: if Cardinal(AIndex) >= Cardinal(FCount) then By the way - putting all cases into the same binary often influences results and even the order in which you execute them changes the output - I had a similar case where just changing order made one or another faster or slower. Measuring performance is not as easy at it sounds :)

Any pure speed benchmark would be rather useless/biased because it all depends on what you are in fact doing apart from creating the list. If this workload is small enough the object creation would mean a significant overhead. In the end you would just benchmark object creation. Also what affects performance is pointer indirection and memory, CPU cache. In some micro benchmark this would not occur as all memory fits into L2 or even L1 cache. Benchmarking the effect on heap usage/fragmentation is way harder because that cannot be done in pure isolation and usually only manifests in production. FWIW performance for System.Generics.Collections.TList<T>.Add (and other methods) between 10.2 and 10.3 also differs quite significantly (got better). And another thing that sometimes significantly improves performance when adding items to a list is to preset its Capacity to avoid reallocations - in the example given in the blog article with adding 64 integers this already improves performance by 33%.

Turn ZBS off for that code and use 1.

Yes, and performance of these things sometimes heavily differs between the different CPUs (for example I had a case where I got some severe slowdown in some code on my ivy bridge i5 whereas it was not there on a skylake i7 one). Anyhow not having a jump is still better than a predicted one. But that is micro optimization (which I did invest some time into as the code I was testing is core framework code, which I usually consider collection types part of).

No. I don't know about the ARM codegen but on windows if you do the pattern: if out of range then raise exception; do stuff; This always generates a jump above the raise to get to do stuff for the common case of "in range". When you write: if in range then do stuff else raise exception; In this case you don't have a jump for the common case of being in range. Depending on how you structure the code you then have two returns in each branch of the if so no jump inside the method. If you like to inline this method it is also a good thing to put the raise exception into its own subroutine to not bloat the inlined code.

And if you then write the Add and GetItem methods better so they don't do unnecessary jumps every time and can be inlined it will be even faster.

What's also interesting about Length and High is that if you are just writing code that directly compiles into a binary they are being inlined by the compiler whereas if you are using them in units that are pre-compiled as part of a package (if you are 3rd party component vendor for example) they are not and always cause a call to System._DynArrayHigh and System._DynArrayLength. Funny enough this is not the case for the source shipped with Delphi because their DCUs are not generated from their containing packages.