David Heffernan

What about multithreaded programs?

That's nice. But it's off topic here.

I don't think you understand. You talked about a .net class, but we are talking about the Delphi RTL.

Well yeah, that's to be expected. And it's not just QPC. If the processor runs in a slower mode, then you code will be slower. And of course when you measure it, that will be reflected, no matter how you measure it.

No, that's not what you said. You were quoting an MS document that was talking about the .net System.Diagnostics.Stopwatch class.

You said that you were replacing TStopwatch with QPC, but TStopwatch is implemented using QPC. So this entire effort is pointless. That's my point. TStopwatch.Frequency comes from a call to QPF. TStopwatch.GetTimeStamp is QPC. And TStopwatch.ElapsedTicks is the difference between QPC when you started the stopwatch, and QPC when you called ElapsedTicks. I guess you were previously calling TStopwatch.ElapsedMilliseconds and wanted more precision. Which you can get by switching to TStopwatch.ElapsedTicks.

There aren't any options with QPC. It just returns a 64 bit int. Which TStopwatch passes on to you. And the performance counter frequency is also available. The only possible explanation for this entire thread is that @Mike Torrettinni has not realised this. I guess he is blocking me because otherwise he would read my posts and realise this.

Why don't you use OnMouseDown?

Am I the only one who finds it odd that we have a two page thread on replacing TStopwatch with QPC when in fact TStopwatch is QPC. Perhaps somebody else could point out to @Mike Torrettinni that when he says It's actually what he had originally with TStopwatch.

I don't understand why you don't just use TStopwatch......

You really should not be trying to manage allocation manually. Your should try to avoid that.

Uff, I didn't read your code properly. I assumed you were using TList. So, yeah you just declare a local variable of the record type, populate it, and add it. As Stefan says, clarity on value vs reference semantics is key.

You would destroy those items using Dispose, since you made them with New. But that's the wrong solution. Use TList<TReminderItem> which will give you a type safe collection whose items are allocated and destroyed by the list itself.

TStopwatch is implemented on Windows using QueryPerformanceCounter......

Doesn't seem like ProcessMessages is really relevant here. Nothing is calling ProcessMessages.

Run in the debugger. When it hangs, use Run | Program pause to pause execution. Look at the thread window, and double click the main thread since I guess that is the thread which is hung. Look at the call stack window which will tell you what the thread is doing that is not completing.

Why does this bother you? Why don't you want to use System.Math?

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.