Leaderboard

Possible but unlikely. I can compile SuperLemmix but I can't run it since I'm missing all the external assets. So instead I went back and looked at the original FastMM leak report. TGadgetMetaAccessor is owned and destroyed by TGadgetMetaInfo. TGadgetMetaInfo is created in 3 different places; Two of them are inside TGadgetMetaInfoList (a TObjectList) and those appear to be fine. The last is in TNeoPieceManager where we have a case of exception swallowing that will lead to a leak: function TNeoPieceManager.ObtainObject(Identifier: String): Integer; var ObjectLabel: TLabelRecord; MO: TGadgetMetaInfo; begin try ObjectLabel := SplitIdentifier(Identifier); Result := fObjects.Count; MO := TGadgetMetaInfo.Create; MO.Load(ObjectLabel.GS, ObjectLabel.Piece, fTheme); // Leak if exception here fObjects.Add(MO); except Result := -1; end; end; So there's (unsurprisingly) problems with exception handling. With that in mind I searched for "except" and reviewed all the cases of explicit exception handling. Many are misguided but harmless but there are a few serious problems. For example in TBaseAnimationSet.LoadMetaData there's a double-free in case of exception: procedure TBaseAnimationSet.LoadMetaData(aColorDict: TColorDict; aShadeDict: TShadeDict); begin Parser := TParser.Create; try [...] try [...] except Parser.Free; raise EParserError.Create('TBaseAnimationSet: Error loading lemming animation metadata for ' + ANIM_NAMES[i] + '.') end; [...] finally Parser.Free; end; end; In TNeoLevelEntry.LoadLevelFileData there's a leak on exception: procedure TNeoLevelEntry.LoadLevelFileData(aExtent: TNeoLevelLoadState); [...] try TalInfoLevel.LoadFromFile(Path); for i := 0 to TalInfoLevel.Talismans.Count-1 do begin CloneTal := TTalisman.Create; CloneTal.Clone(TalInfoLevel.Talismans[i]); // Leak if exception here fTalismans.Add(CloneTal); end; except // Fail silently. end; [...] TNeoLevelGroup.CleanseLevels is a complete mess and can leak a TStringList on exception. TNeoLevelGroup.LoadUserData will leak a TParser on exception.

Thank you guys for your hints. After investigating further, it seems indeed that there are some memory allocation issues. I started fixing them and both the monothread version and the multithread version are now faster. I'll revert back here when I am done with this process.

The terminology in the quoted text is muddy, IMO. Reintroduce does not affect the compiler other than suppressing a warning. You will get the same code emitted whether you omit the reintroduce keyword or include it. When you use the keyword you are just telling the compiler you intend to do something that kind of looks like a mistake (hiding the inherited method), because it is not common to declare a method in a child class that has the same name as a virtual/dynamic method in its parent and not also override it. (There are times where this makes sense but I personally try to avoid it because of the inevitable confusion it may cause down the road when it is forgotten this was done...) It's also sometimes the case that the inherited class changes: someone adds a new virtual method that didn't exist when the child class was designed, and now there is an unknown conflict; the warning is a good one so you can know this happened and deal with it accordingly. I can't understand from your post what you actually want to do, so I can't offer you an alternative that works around the confusion.

I wouldn't use a separate flag unless necessary. If you are using a TDataSet descendent, you can look at the State property to determine whether the record is being inserted (State = dsInsert) or edited (State = dsEdit). If it is necessary to call Post in code, you can use if ds.State in dsEditModes to determine if the current record needs to be posted.

You are editing a client, period. It shouldn't matter whether it is a new client or an existing client. So, using a simple flag (or other indicator telling you the client's state) to adjust the Form's behavior accordingly should suffice, no need to duplicate the work unnecessarily.