David Heffernan

Why Delphi? Why not use something else?

80 bit was never for large precision. It was intended for use as intermediate values in calculations for accuracy purposes. But it turned out not to be worthwhile. That's why it has been dropped. The support in modern hardware for 80 bit is on the 8087 unit only and is horribly slow. It's there for legacy reasons so legacy code still runs. Perhaps you are doing different type of work from me. But I'm using BLAS type numerical algorithms. You don't find BLAS for 80 bit data. This is an interesting post https://retrocomputing.stackexchange.com/questions/9751/did-any-compiler-fully-use-intel-x87-80-bit-floating-point

Indeed. And too bad you can't specify the type of a literal.

Given that the suppliers of hardware have dropped support for extended I would suggest that you are out of date.

Don't you have any software developers?

What is stopping you from writing this in Delphi? I don't fully understand the question? Do you have any programmers on your team? Why not ask one of them to do this?

True, but nobody should be using that type anyway. I speak as a developer of mathematical software.

FWIW, I'd tackle this by shipping a 64 bit application.

It's true that the 64 bit Windows debugger is a disaster zone. But I just debug with the 32 bit debugger. You can have a project with both 32 and 64 bit targets. You can then ship just the 64 bit if you prefer. But you can still use the 32 bit debugger during development, because it's the one that is actually useful.

c# - 32-bit OpenFileDialog --> 64-bit System32? - Stack Overflow tl;dr not possible

Then I think the code from @Lajos Juhász is what you need

What data type are you using? Currency?

The winapi heap is what I use for my MM. With an added twist that I have distinct heaps for each NUMA node so that I can arrange that threads get memory that is efficient to access on NUMA machines.

Using a GUI timer like this is likely wrong anyway.

This is surely correct. It's strange that people wouldn't be happy to have the allocator in a dll.

Pointer with increment vs direct array indexing should be very similar. In anything I think the latter tends to be a little quicker.

I simply don't use the RTL collections anywhere in my code and use my own implementation so I have full control of that. This is a serious undertaking, and not for everyone. So I'd recommend using the spring4d collections.

I agree. My point is that OP keeps asking for buffering but that won't really help.

Buffering isn't really going to help here, because the MM already does that in effect.

I'm not sure what you are saying here. Writing to memory is just writing to memory. Be it some intermediate buffer or the memory block backing the stream. Can you explain what performance block you are trying to overcome. Reallocation is the only block I can see.

Rather than buffering in this case I have a memory stream that doesn't use contiguous memory. Instead of a single memory block, it manages a list of equally sized blocks. This avoids any performance issues with repeated calls to ReallocMem. Is that the performance block you want to work around?

Easier to replace the CRT monitor with an LCD

Do you perhaps have code in different modules? Like code in an exe and a dll and the object is passed between the modules?

I guess I'd be a bit concerned about floating point use here when Log10 returns an exact integer

Seems like the problem is going to be in the code that we cannot see. Please make a minimal reproducible example.