David Heffernan

I would expect so, but I don't know for sure. I do know that when using HeapCreate / HeapAlloc this is true, but that's no use to you. I do have a NUMA machine to hand and would be happy to run some tests on it if that would be useful for you.

My question was based on my own experience running multithreaded floating point software on NUMA machines, an issue that was live for me maybe three years ago. My problem was that most memory managers allocate out of a shared pool, but that cross node memory access is much more expensive than within node memory access. I didn't find any Delphi memory managers that were both robust and able to allocate memory local to the node on which the calling thread was executing. IIRC, allocators such as that of TBB and others used in the C++ world were able to do this. My application is a little different to more mainstream Delphi applications however. I understand that fastmm targets usage with frequent allocation of relatively small objects. In my application I preallocate wherever possible and avoid allocation in any hotspot. So my goal could just be boiled down to achieving affinity to the local node. In the end I wrote my own memory allocator on top of HeapCreate / HeapAlloc etc. The strategy is the each NUMA node has its own private heap (allocated by a call to HeapCreate). Each allocation is performed on the heap associated with the calling thread's node. I'm not in any way suggesting that such a simple strategy would be appropriate for fastmm. The interesting thing that I observed is that raw heap allocation / deallocation performance was never a problem for my app, because of the efforts we took to avoid allocation in hotspots. Likewise for thread contention, for the same reasons. The issue was that memory access speeds in my app is a key performance factor. And cross node access has dire performance.

Fine if you are multiprocessing, but not if multithreading.

Unlucky for you. We've stopped supporting Windows 7, after all MS doesn't anymore.

BPL not corrupted. Just a defect in some code that runs inside the IDE.

Would be interested to know whether NUMA memory is handled well.

Regarding timers and energy use: https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

You asked the same question on SO: https://stackoverflow.com/questions/61505887/thread-programming-without-sleep-or-waitfor-events It was closed there because it lacked focus. You seem to be wanting advice to a level of detail that far outstrips the level of detail used to specify your problem, and your current solution. In my view you are unlikely to be anything much out of a question asked the way you did. I recommend that you step back and provide a lot more detail and background. That will give you more hope of getting relevant advice.

https://stackoverflow.com/q/19054789/505088

It's quite possible to solve your problem, but what you are proposing is not the solution. Solve your problem by responding to the underlying messages. If you have issues with flicker, they can doubtless be solved.

This looks badly wrong to me. What problem are you trying to fix?

Do you observe incorrect behaviour of your program?

This provides no clarification to me. Now I think I have no idea what you are asking.

You can't declare an encoding instance to be a default parameter value because it is not a constant, never mind a true constant. Hence the compiler error. So you have to resort to overloaded methods. Declare one method that accepts an encoding parameter. And another that does not. From that second overload call the first passing your chosen default encoding.

Default values need to be true constants. This is not. You are confusing default encoding with default parameter value.

Not needed. Really not a great idea to suggest needless actions with no basis in fact. Just spreads FUD.

When the debugger evaluates some variables to display values in the debugger it often leaks memory. This is a defect with the debugger. The code here does not leak. Any reported leaks are due the debugger. I see this very often with property getter functions that return strings. The debugger calls the function, creating a new string. But then the debugger fails to destroy the string. Leak.

Why did you choose hex? Isn't base64 a better choice?

Seems odd. Why don't you return binary?

It is not interesting. Also, no guarantee that invalid pointer leads to access violation. Corrupted data is perfectly possible.

There's a huge difference between making an unintended mistake after having done your best not to, and intentionally harming. It's surely not difficult to see.

Tell that to the lawyers. Of course it matters.

Seconded.

FlexNet

VTune works well. AQTime was an unmitigated AV fest when I last tried it.