Anders Melander

Okay. Now the use of W2K makes much better sense. Interesting constraints. Anyway, back to the problem. If you can observe that virtual and physical memory consumption increases during execution, but all resources are released before the process is terminated (thus no leaks detected), then you can force the allocated memory to be reported as leaks by terminating the application prematurely with a call to Halt.

That makes good sense, but why limit virtual memory? Doesn't the devices have hard disks?

You should probably rephrase that "and only slows me down". In my experience laziness always comes at a price. Not bothering to use descriptive identifiers saves a few keystrokes at the price of readability. ARC and GC relieves the developer of having to deal with some of the complexities of resource management, at the price of performance. Etc. I would honestly rather have good performance and full control of what's going on with the resources. Yes. Let's break COM support so we can save some keystrokes.

How is that relevant to the topic?

FWIW, Windows 2000 isn't supported by the version of Delphi you're using. Also, please read the event log message again. It has all the clues: It isn't your application that is experiencing an "out of memory" error. It's Windows that is experiencing an "out of virtual memory" error. To fix it: Increase the size of the page file. My guess is that the W2K system has a fixed size page file - or no page file at all. Otherwise it would just increase the size automatically - or maybe that feature was added later. I forget. and who cares anymore. If you're really interested in why you get a windows error and not an application error, read some books on Windows internals and the virtual memory manager, or just google it.

You're not giving us much to work with here. Do you have any documentation about what kind of data ReadFromMemFile expect the input buffer to hold?

You didn't really answer @Vandrovnik's question. For Windows bitmaps the bitmap file image (i.e. bitmap header and pixel data) isn't stored in memory. When TBitmap loads a bmp file it reads the header information then the pixel data. From this it stores the relevant meta data (width/height, color depth, palette, etc) and pixel data in memory. Of these you only have direct access to the raw pixel data. If you need the file bitmap image in memory then you will either have to save the bitmap to a memory stream or construct the image yourself in memory. btw, when I write "image" I don't mean in the picture/graphic/bitmap sense. Maybe you should try to explain what problem you are trying to solve.

Technically it's the page file. The terms page file and swap file have their roots in VMS. Both Windows NT and VMS were designed by his holiness, Dave Cutler. The swap file doesn't exist anymore in Windows (I believe it was there in early versions) but was used when a process working set was completely removed from physical memory. E.g. in low memory situations or if the process went into extended hibernation.

No. You still don't understand the difference between physical and virtual memory.

Please google "64-bit"

True, but even in 2003 it was a 16-bit leftover from the DOS days.

Please google "virtual memory".

Try Documentation Insight. It supports both XMLDOC (which I agree makes the source unreadable) and external documentation files: I've been using it to generate library help files (in CHM-format) but it can also display the help as tooltips in the Delphi editor.

What breaking changes are those? At one of my clients we upgraded all projects (many millions LOC) directly from Delphi XE & XE2 (for 64-bit) to Delphi 10.2 with no significant effort. The worst part was the tasks you'll have to do anyway every time you migrate a project from one version of Delphi to another. If they had kept up to date all the way through, they would have had to pay maintenance on 20+ licenses to get the occasional new feature they didn't really need and they would have had to fix and work around all the new bugs they got as well.

Windows does a better job of making old applications behave well under high DPI than the VCL has so far managed. I would prefer to have the UI consistently scaled than having some parts support high DPI, some parts scaled and some messed up.

You must love the Windows Update policy in Windows 10.

Yes, we've had that discussion already. No thanks.

Probably not, but either use Duplicates=dupIgnore or do the test manually. Don't do both.

IMO it's not that clear what he needs. dupError is set which means that duplicates should cause an exception, but the code explicitly produce duplicates - and prevents them from being added. Anyhow, I don't think I have anything to contribute on the topic that a quick google search couldn't have provided in the first place.

Here: Okay, but setting Sorted=True and then adding to the list will keep the list sorted; It's using binary search to find the insertion point so it's not that bad, but it might be better to add unsorted and then sort at the end. It depends on the dataset.

Tell them you agree. If the applications are in maintenance mode then I don't see any reason to upgrade, potentially introducing new problems with no benefit to the company or its customers. Keeping Delphi, and 3rd party libraries, up to date is a costly investment and unless a product is being actively developed that investment might not yield a sensible return. Whenever someone mentions the idea of a completely rewriting something from scratch I simply respond "Like Netscape?" https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ I've been through a couple of successful complete rewrites myself, but they were architectural rewrites that were done incrementally. We basically refactored everything one tiny thing at a time until we finally arrived at the destination, many years later. And we stayed with Delphi. An incremental rewrite isn't really possible when you're replacing the platform.

I see. But I'm guessing the introduction of a lock, even if it's a spin lock, might influence the thread schedule. IMO an interlocked increment would have been better for the verification part.

Is that change relevant to your patch? It's hard to compare the results when more than one factor has changed.

It's a bit hard to see what exactly it is you're benchmarking with that code. Your first loop is supposedly meant to measure Add performance, but it also contains a Lookup. And after the first iteration of the outer loop it just produces duplicates, but then skips all those duplicates. Also your test is too synthetic. Use realistic data instead. I'm guessing your actual data isn't all possible three character strings with perfect distribution... And is sorting the stringlist after each insert really a realistic scenario? If you're really that interested in the performance of your dictionary I suggest you profile with real data instead of this guesswork.

Have you tried installing the fonts manually on these machines?