Erik@Grijjy

Delphi 10.4 is just around the corner and you have already been reading about its exciting new language and IDE features. But what has been getting less attention - and what I find equally exciting - is the addition of Metal support for macOS and iOS. See why this can be important for you too as well... https://blog.grijjy.com/2020/05/25/boost-mac-performance-with-metal-and-delphi-10-4/

I present a simple technique that uses a combination of generics and static class variables to map any Delphi type to a simple integer index. And why you would want to... https://blog.grijjy.com/2020/04/21/mapping-delphi-types-to-indices-at-compile-time/

Are you using 3rd party C libraries in your Mac app? Or maybe some custom assembly code? Then things will be different when you switch to 64-bit macOS. Maybe this post will give you a head start. It shows how you can use static libraries now, and how you can use an external assembler for your assembly code. https://blog.grijjy.com/2019/07/19/using-static-libraries-and-assembly-with-64-bit-macos/

No, like almost all YAML parsers, it does not pass all the tests in this test suite. Since this library is build on top of LibYAML, it fails and passes the same tests as LibYAML does. I have included this test suit into the Neslib.Yaml unit tests though, but excluded the tests that are known to fail with LibYAML.

That definitely makes it easier to work with YAML if you are familiar with JSON. YAML 1.2 is even a superset of JSON, so it can parse JSON as well. Unfortunately (or maybe for the better), libyaml only supports YAML 1.1.

Yes, my library isn't really suitable for very large files, since it loads the entire file into memory. Since YAML is used a lot for small(ish) files, I wanted to keep it simple. I may add a SAX type interface at some point. Libyaml already provides a such an interface (it is what I used to build the DOM) and it could be adopted to something more Delphi-friendly...

Just finished a personal project for consuming and creating YAML in Delphi: https://blog.grijjy.com/2019/06/03/a-yaml-library-for-delphi/

You are mostly right about this. If you have a small list size, you are mostly measuring creation/destruction time. But that is exactly one of the reasons you may want to use a stack-based list instead. Although my main motivation wasn't about speed (it was more about memory fragmentation, which is hard to test as you mentioned), I added some speed tests to the repo anyway. Like you said, any speed test in this area is biased, and does not represent a real-life situation, so you should take the results with a grain of salt. I tested 4 stack list implementations against Delphi's TList<Integer>: TStackList1 is the original stack list from example 2 (with a fixed configurable size, but doesn't allow managed types). TStackList2: as TStackList1 but takes Stefan's "put exception at the bottom" suggestion into account. TStackList3: as TStackList2 but uses inlining TStackList4: as TStackList1 but uses inlining I tested these lists with a buffer of 256 bytes on Win32 using Delphi Rio. This shows how much faster each list is compared to Delphi's TList<Integer>. TStackList1: 2.78 times faster TStackList2: 2.77 times faster TStackList3: 2.81 times faster TStackList4: 3.03 times faster Note that measurements vary a bit from session to session. Sometimes, "putting the exception at the bottom" has a positive impact, sometimes it doesn't. TStackList4 is always the fastest on Win32 though, but the differences aren't that big. On Win64, the results are about the same, but Delphi's TList<Integer> seems to perform a little bit better than on Win32. Also, as you said, performance depends a lot on the list size. For a list size of 32 bytes, the stack lists are about 10x faster, but for a list size of 2048 bytes, they are only about 1.7x faster. This reinforces my suggestion that stack lists are most suitable for smaller temporary lists. For larger lists, just stick to heap-based collections instead. And you can tweak the capacity as you mentioned to avoid re-allocations. You can't really test heap usage and fragmentation with these tests. Because we are creating and destroying lists in a loop, a smart memory manager just reuses the same heap memory over and over again without fragmentation. In real-life however, there will be lots of other things going on between the recreation of lists, and fragmentation will be more likely.

You mean by moving those checks to a separate method? I noticed that method calls are pretty expensive on ARM devices, so I don’t know if it would increase performance in that case. Worth some testing... We could also assume that the programmer knows what (s)he is doing and remove the check or replace it with an assertion if speed is really that important...

You are right, it is only heap-allocation free. I think I clarified that in the post. And as I said at the end, "use if appropriate, not just because you can". So if you are running on 32-bit in IIS, then don't use it with large buffers. Small stack-based collections (256 bytes up to 1KB) can still be useful in those situations though...

A generic list that doesn't use any heap memory? We show you a couple of ways to create one in our latest blog post! https://blog.grijjy.com/2019/01/25/allocation-free-collections/