David Heffernan

Are you measuring address space fragmentation?

It's just calling methods and accessing attributes. No different for pandas than for any other library.

Delphi's memory manager is fastmm. Also, your tool to measure the effect of the program isn't really telling you anything. It says nothing about fragmentation of address space. Virtual memory is a very complex subject. I suspect you need to learn more of the details before you can reason about your program.

Seems a bit needy

Agreed. Why would the main form destroy itself before the code in the dpr completes?

There are lots of posts on this topic on the madExcept forum. Websearch with the obvious search terms will find them.

You seem to be wanting to change your program, but now you tell us that you can't change it. Seems like a waste of time.

If you can't change anything, I wonder what this topic is about. Is it a thought experiment?

You don't need to change them. You just need new versions of your existing glyphs.. You'll need to hire a graphic designer.

You need to spend some time and establish some basic facts. We can't give you meaningful help on this basis.

Clearly you have got some code. The code is what you are trying to compile. The error message tells you what line of code causes the error. If it used to compile, something changed. What?

Do you have any code?

It's kinda lame that they still haven't addressed this. It's been an issue since Delphi 1. The tech exists. They can already dynamically load and unload packages.

This seems like a much better approach to me. And as soon as you have to deal with different versions of a library, then aren't you forced this route?

You have different SVG files for different icon sizes in some cases?

But scalable doesn't tend to be right for icons because you often want to tailor the icon to the size. So a small version of the icon might have quote different content from a large version.

I don't think SVG is the right way to handle scaling of icons. Why do you think that?

I don't. I skip that step where you reinstall Windows!

Well, yes. That's part of the contract. SetLength is contracted to return a unique object, that is with ref count 1. It's even documented! http://docwiki.embarcadero.com/Libraries/en/System.SetLength "Following a call to SetLength, S is guaranteed to reference a unique string or array -- that is, a string or array with a reference count of one.“ The only scenario you've raised that I could see being troublesome is a copy for weak refs. Everything else isn't going to have discernible real world impact.

I'm just saying that it's very unlikely that there will be real world code that suffers. That said, I don't know about weak refs so that could be significant.

OK, so no copy, and not much else, unless it's a jagged array or has weak refs.

It was you that referred to jagged arrays. Once you start using them, for rectangular data, you've given up caring about performance. I didn't see any copying when I looked at this. I don't see any evidence that performance is a significant issue here.

I wouldn't overplay this. Jagged arrays have terrible performance. Your problem is not that all these ReallocMems can be skipped, but aren't. Your problem is that you are using a jagged array rather than a multidimensional array. Your problem is that you did 101 allocations (not 1000) rather than 1.

It's just a realloc of a block the same size, which is a null op and nothing happens. Unless you have a pathologically insane memory manager. But no memory manager I know of would do anything other than null op for this realloc.

But, at the end, do you, or do you not, end up with an array that is the correct length, and respects the contents that existed before you called SetLength? If perhaps you are worried that there is a performance hit, measure it. I can't believe we would still be having this debate about premature optimisation. You remember us mentioning this to you before? If you want to make your code run faster, why don't you optimise the parts that take the most time?