Leaderboard

What could possibly go wrong

If the OP would explain the original motivation behind this, then we could propose proper solutions to the actual problem. This is a canonical XY question.

😎

I was talking to someone the other day about this too. I had thought about creating an IDE add-in to effectively "lock the form," where it ignores all those "accidental" changes. I think it would be really useful to also ignore things like active tab in the tab control, etc. Usually when I'm submitting changes in source control I only want to submit the minimum changes for the fix I made, but then I want to make sure that that subset works, so I have to revert unneeded changes, test that code state, and then submit it. So a filter or lock would be really helpful.

Here is my MemTest unit which I use together with WinMemMgr, in all my productive applications: https://github.com/thatlr/Delphi-SupportUnits/blob/main/source/MemTest.pas

Replace: //l_vec3 := k_vect3_nul; //option 3 move(k_vect3_nul, l_vec3, sizeof(t_vect3)); //< Edit with sizof(type)

You can't add a new property to all components. But, the existing Tag property is a NativeInt, so it can hold a String (which is just a pointer under the hood), eg: var tagStr: NativeInt := 0; String(Pointer(tagStr)) := SomeString; SomeComponent.Tag := tagStr; ... var tagStr := SomeComponent.Tag; SomeString := String(Pointer(tagStr)); Just make sure you release the String properly before the Component is destroyed, eg: var tagStr := SomeComponent.Tag; String(Pointer(tagStr)) := '';

@PeterBelow It is even possible to inject new properties to the Object Inspector. In Cmon.DataSense.Design.pas I use this technique to add a DataSource and DataField property to supported controls. The additional data is stored in a special component (TDataSense) using a dictionary internally:

I see Top/Left/Width/Height/ClientWidth/ClientHeight change a lot, too--and I'm pretty sure I don't move those components every time I open a form.

This is the unit @Stefan Glienke was referring to. 100 lines and it uses no other unit!

That benchmark proves almost (*) nothing, the only point where it allocates is during the form creation where it builds the card deck and later when it prints the output into the TListBox. (*) the only thing affected here is the possible layout of the card objects in the heap as they are all read during the hand-processing code. The difference that you can observe here between Delphi buids using different memory managers is most likely caused by the amount of overhead the respective memory manager is using thus fitting more card objects within the same memory pages, thus more of them (most likely all on modern processors) fitting into L1 cache. As for this particular code - removing the name of the Cards from the object and only building it when it is needed for some UI would probably speed up code more than anything else because you get rid of 20 Byte for every object (Name is a string[19]) - on my CPU this makes the code go down from ~900ms to ~680ms - simply because it does not need to copy the strings in CopyCardFromDeck. Circumventing the getter and setter of TList (which contribute around 25% of the remaining time) brings it down to 460ms. And after that we are not done with string stuff - in every loop iteration, it calls Hand.SetHighValues which produces a name for the cards on the hand - removing that gets me down to ~400. Now because I have a run and SamplingProfiler open already I see that now one of the scorers is TcaaPokerHand.CopyCardFromDeck - the Items getter is not inlined which causes it to be called 10 times for the same 2 card objects. Changing that gets me down to 270ms. But how about avoiding repeated access to the same object in the 2 lists altogether? 230ms I could go on because I see a lot more room to optimize - but I think I made my point. Instead of fiddling with the memory manager one should first look if heap allocations are even the issue. And then identify unnecessary work and eliminate that. ... change TcaaEvaluationCard to be 8 Byte size - (that avoids that the compiler creates a movsd/movsb instruction but simply does an 8 byte mov) -> 160ms