David Heffernan

Does ExportGridToXLSX convert XLS extension in filename to XLSX?

xlsx or xls?

I'm not disputing that. All I was trying to say, all along, is that the issue is not to do with file attributes.

Correct. Also correct, if the file does not exist, then INVALID_FILE_ATTRIBUTES is what you'd get. Which is what I said.

INVALID_FILE_ATTRIBUTES is what you'd get if the file did not exist. It doesn't mean there is a problem with the file attributes.

That's going to be pretty slow then. I'm not sure you are going to be able to combat that. I find it a little hard to believe that your C++ experiment with 200ms for 1mio iterations had the loop in C++. C API for Python of course works fine under Windows 10, so your silent crash is going to be solvable.

Put the loop into the Python script. It's the transition from Delphi to Python and back again every iteration that is killing the performance.

You can't always achieve not using heap allocation. What you can do is reduce heap allocation. Which is one of the reasons for using SB. Good advice, but hard to achieve due to their paucity.

Again, for a heavily threaded program then thread contention becomes a bottleneck with heap allocation of FastMM.

I guess if there are no firm rules on the expected behaviour, then that makes it easier to write faster code.

Do you have a specification about what you want the function to do? It seems like you don't mind.

One of the big issues with heap allocation comes when you have multi threaded code. If your benchmark doesn't test that and you do have multi threaded code, then your benchmark is likely not very useful.

The simple solution is to put this code in a DLL. Use a side by side assembly manifest to make it self contained.

I'd design the code not to use global vars.

Isn't this the section that is not picked up when linking 64 bit .obj files? Hence leading to problems (like instant process termination) when an exception occurs in such linked code. Or have Emba addressed that in more recent releases?

The code is something of a disaster zone. That leak looks dire. If the component contains this, then who knows what else is there! As for the two minute fix, I gave that above. Replace temp[1] with Pointer(temp)^. But we're still making assumptions because we can't see the exception details.

Why are you using WideString? That's a type for COM interop. Shouldn't temp be string? You leak Buffer. Why do you allocate buffer so that you can copy temp to Buffer and then to reply.buffer? Why not copy direct? Why use Move and CopyMemory? They do the same job. Pick one and use it consistently. What do you do to defend against buffer overrun of reply.buffer? If your code raises an exception, that exception is raised at a specific line, and has a specific message. That information is useful. That you didn't include it in the post suggests that you have not studied it in detail. I bet that it tells you information that would help you understand. And certainly would help us understand. What is that information? The blanket exception handler also looks pretty nasty. That's going to convert all exceptions, no matter how they arise, in to the same error condition. We can guess that temp[1] trips up range checking. But the exception message would remove any need for guessing. Btw, you fix that by using Pointer(temp)^ in place of temp[1].

I don't think @Der schöne Günther was doubting you, just noting that what you were doing seemed correct. Can you make an MCVE and submit a report to Quality Portal?

The code in the original post doesn't. Kinda makes a difference. Still, it's not an important difference as it happens. You have no real need for a hash table based loopup. An array is fine for lookup. You can then use sets additionally.

FWIW, my current codebase has this: procedure TOrcForm.DestroyWindowHandle; // DestroyWnd is not called from the form destructor, so we override DestroyWindowHandle instead begin FreeAndNil(FDropTarget); WTSUnRegisterSessionNotification(WindowHandle); inherited; end; So I guess that's why I said "it rings some bells" in an earlier post.

The point is that many Delphi developers use double buffering to solve problems with flickering when resizing, rather than solving the root cause of the flickering. My experience of double buffering is that whilst it might deal with flickering, it also introduces its own problems. For instance, it changes the appearance of your program if you are using the Windows theme. I don't want that. So I don't use double buffering. And I don't have flicker on resize.

Really? That's upsetting. Although it rings some bells. But it won't matter here because process termination will lead to the system tidying up. Ill have a look tomorrow.

This code fails under VCL window recreation. Hence the Emba code. My answer to this old SO question presents a different way that may be simpler in the long run. https://stackoverflow.com/q/4854534/505088

I only use WriteBuffer myself, FWIW. WriteData was a bad mistake.

Not really namespaces as would be useful in this context.