David Heffernan

I don't see l any good reason why the IDE stability would have anything to do with hardware. It's just bug ridden. Those AMD processors are pretty tasty. Gamers love them. But they are way over powered for Delphi. Most important thing you can do for Delphi IDE perf is have a good SSD.

I meant the startup cost for the developer to learn how to create and maintain and deploy com servers.

Whether you opt for pinvoke or a COM server depends very much on what the interface surface area looks like. I don't think anybody can give you a valid recommendation without knowledge of that. Broadly speaking, for more larger and more complex interfaces, then a COM server may be preferable. For simpler interfaces, then p/invoke may be preferable. It is more effort to setup a COM server (especially if you have to learn COM), but having done so the coding on both sides will likely be simpler. For larger and more complex interfaces the startup cost of a COM server will yield time savings to offset that. For an interface that can be represented by a small number of functions, then you will never recover that startup cost, hence why p/invoke would win. To my mind at least those are the main factors to consider in your decision.

What other tools use pdb? I think pdb files can be used to get stack traces in Process Explorer and Process Hacker 2. Obviously there is Visual Studio and there must be many others. I wonder if anybody has tried using the pdb files generated by map2pdb with other tools such as these.

Hope you and your family recover fully @Lars Fosdal.

The fact that the term "scalable memory manager" exists shows that heap allocation is a particular issue for multi-threaded programs. That's the same point that I have been making.

Selecting text in an edit control is for sure a use case where this is needed.

Amazing work. Well done!! Thank you. Although it can't be compiled in older versions, presumably it works with programs built with older versions of Delphi? And do you have plans to support 64 bit?

I don't think this is true. TEdit is the Win32 EDIT control. What are you doing with strings that need to know what you are asking about? What's your usage scenario?

Why would you need to know this, unless you are rendering the text

Isn't that going to claim a global lock 31 times?

Put the labels in an array, and then access them by index, or Use a single label, and include linebreaks in the caption, or Create the labels dynamically, or Probably some other solutions that I have not thought of.

It's always a good idea to minimise contention on process wide locks, which is why it is best not to call SetLength over and over when that can readily be avoided.

Thus can't work. You need both sides of the interface to use the same memory allocator and the same dynamic array implementation. Which ties you to specific delphi versions. That forces your plugins writers to use Delphi. Amongst other requirements.

Really? Contention on a lock has the same impact irrespective of how many items are in the collection.

Well, won't they suffer when you make lots of reallocations. That's always been my experience.

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.