David Heffernan

It's a fixed length array, so it's a value type. Which means that when you pass it as a value argument, it travels via the stack. If it were a dynamic array then it would be passed as a pointer to the first element. Not that strange really. Changing from 32 to 64 bit is significant. You've been getting lucky up until now. All that copying of huge objects must cost a lot of time and make for inefficient memory usage. Mindset is important here. It's very rare that you will find compiler bugs (even with the Delphi compiler!) So always suspect your own code first.

@marcocir start from the assumption that the compiler is correct and that your code is faulty. That's far and away the most likely explanation. With that mindset, read Arnaud's answer again.

Are the collections in mORMot generic? Because if not then there's no way to make a fair comparison.

Whatever you do, don't use floating point arithmetic!

@David Schwartz Are you familiar with how C# implements out params. Why can we have that?

It would be nice if that documentation was accurate, but it's not. You will have no problems passing a non-nil instance into that function using an out param. You'll find, at least for non-managed types, that out and var parameters behave identically.

Back in the day 16 bit Windows GDI used 16 bit coordinates, so the issue could very easily be a hang over from code written in that era. Either in the Windows API or in the VCL.

Your problem is with this memcache class. That's what you need to fix. Shouldn't be using AnsiString.

Only you know what your memcache is doing, but I'd guess that it uses an 8 bit encoding, perhaps AnsiString. You need to understand a problem before trying to solve it.

I honestly don't think that the issues discussed in the answers so far should be a primary factor in your choices.

See the penultimate para in my post where I explain exactly how to do this

You won't have any problems with encoding Delphi string objects. What you do now seems to be to as follows: 1. Read a UTF-8 encoded file and convert that to UTF-16 encoded array of string. 2. Create a new string object by concatenating all the strings from the array created in step 1. 3. Base64 encode the string from step 2, which creates another UTF-16 encoded string, but a larger one, because that's the nature of base64. This looks very inefficient to me. I don't know what your memcache code works with, but it looks like it works with strings. And strings don't have encoding problems, they are encoded as UTF-16. It sounds very much like base64 has no purpose here. It's just an extra step with added CPU time and inefficient memory use. And it can't have anything to do with encoding, because base64 just a bijection between binary data and text data. And here we have text data all the way so base64 must be being misused here. Put another way, you use base64 when you have binary data and want to store it in something (file, variable etc.) that expects text. You have text all the way so there should be no base64. It seems to me that you should just load the file into a string and stuff that into your memcache, which is expecting a string anyway. Use TFile.ReadAllText(afilepath,Tencoding.UTF8) to do that and store that string to your memcache. Then when you need to retrieve and parse it, pull out the string and use SplitString. Even better would be if your TOML parser could work on a stream rather than requiring an array of string. But that's another story.

What's wrong with storing the strings as a dynamic array of string as you already do? Where does base64 come into this?

If you can't avail yourself of 64 bit address space then perhaps you will be best chopping the image up into tiles.

Out params in Delphi kinda suck because the compiler does nothing to enforce out semantics. Compare and contrast with C#.

The map files I create have line info for rtl/vcl units linked from Emba supplied dcus.

You can use the Emba supplied dcus for the rtl/vcl/FMX libraries. You will be able to generate full detailed map files from them.

Why would you wrap a memory map with a stream? You use a memory map when you want to access a file using memory operations. But the stream interface reads chunks of the file in a caller provided buffer. If you want a stream interface I don't see the point of a memory map.

That's a strange way to spell C# and Typescript

Heljsberg clearly made the right decision for his own career and I would argue that the world of programming is better for him having move to MS than it would have been had he not.

The thing is, experts have jobs. They aren't interested in micro payments. As a general rule. I doubt EE has ever paid its contributors or ever intended to. It was crappy website that was justly made irrelevant by a far superior one.

Who would contribute to such a site? What would be their motivation? People wouldn't do it for free. Nobody wants to give away their expertise and have it sit behind a pay wall while somebody else profits. Stack Overflow killed EE with a completely different model.

Don't believe random stuff you read on the internet without evidence.

EE hasn't been relevant for 10-15 years

Who does this help?