David Heffernan

It's not about the memory. It's about removing global variables that allow form instances to poke at each other's internals. It's analogous to making fields private rather than public.  Those form variables only exist because in Delphi 1 the designers were trying to ape functionality of VB.

The entire design seems wrong. Don't use a global variable for each form. Remove them. Use a local variable and destroy it when ShowModal returns.

But this topic concerns the 8 bits in a byte.

Who says that the variation isn't happening in your process?

You'll see similar results as you do presently I predict.

Ugh, a class allocated on dynamic memory just to do bit twiddling. What is so hard about the and operator?

Doesn't seem like a massive amount of variability. Probably depends on what your code does. You are measuring what is known as wall clock time. Total elapsed time. Why would you want to measure anything else? Wall clock time is the time as perceived by the users.

Define "pixel perfect" please

It hasn't been supported for years now. Use an old delphi version for legacy OS like XP.

Don't put them all over the code. Just don't!! There is always a better way.

The fundamental problem sounds like you have duplication of code. Attack that and the problem you describe simply disappears.

In other words, you added these options to your project.

Not much point creating an unmanaged wrapper when the library ships with one out of the box.

There's got to be a convention one way or another. Is it really that hard to grasp?

Generally multiple threads give performance benefits for cpu bound tasks. This one isn't cpu bound. So how do you imagine there to be any benefit?

Very hard to see anything useful coming from this. Can't imagine any way for Delphi to directly consume a managed assembly other than COM. I'd consider making your own COM wrapper of the assembly, using C#, or writing a Delphi wrapper around the C interface.

If it's a numeric column then surely it's always a number.

I don't see that you have to work with variants. I think you can work with text. I work with text when I use VTT.

You are working with Unicode strings so you will always get varUString. I don't know what you have against varUString. Surely you don't want to go back to ANSI strings which is what varString represents. VarAsType returns a variant. That's why you need a typecast to obtain other types. The entire question seems massively over complicated. In fact this is a common theme of the questions you ask. Don't take that the wrong way. But my most important advice to you is to try to simplify. You seem regularly to get tied in knots because you don't reduce the complexity in your thinking. In this instance, surely, you should be working with the user input as text. No need at all for variants in my opinion. Simply use TryStrToInt to check if a string value can be treated as an integer. And if there really is some need for variants due to motivations we cannot see then take care to understand what types they can hold. Make sure that you only ever add Unicode strings and integers and therefore only need to deal with those two var types. Raise assertion exceptions if you encounter other types. Make sure that you have good testing in place. Now, you probably think that you haven't got time for testing but what many people don't realise is that testing saves you time. Testing is what allows you to make changes to code without fear of breaking it.

No you can't.

This is simple to answer. Measure the time of the program running. Everything else is pointless. Don't guess performance questions. Measure.

It will be shutdown when the OS updates. Also, if you want to make it hot upgradeable, make a monlotihic DLL hosted in a thin executable.

Build a monolithic executable and then the problems disappear.

I've wrapped libyaml, which is a bit of a grind but very functional.

But none of that complexity is present here. And even if it was, then you'd still use CreateProcess. ShellExecuteEx would have value with the runas verb only.