Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Werkzeuge (https://www.delphipraxis.net/63-sonstige-werkzeuge/)
-   -   MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks (https://www.delphipraxis.net/197712-madexcept-vorteile-gegenueber-fastmm4-bezogen-auf-speicherleaks.html)

ngott2 29. Aug 2018 15:54

MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Hallo,
gibt es neben den Vorteil, das man bei MadExcept direkt zur Zeile springen kann weitere Vorteile, die für Madexcept sprechen? Oder gibt es sogar Nachteile? Wichtig nur Vorteile, die auf das finden und fixen von Speicher Leaks bezogen sind. Gerne auch eventuelle Nachteile.

Danke und Gruß.

Codehunter 29. Aug 2018 20:50

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Die beiden verfolgen ja eigentlich unterschiedliche Konzepte. FastMM4 ist darauf ausgelegt, bei der Entwicklung zu helfen. MadExcept dagegen konzentriert sich darauf, Fehler in "freier Wildbahn" zu sammeln und Reports zum Mutterschiff zu senden. FastMM4 habe ich schon zu Delphi-7-Zeiten verwendet. Seit der standardmäßig bei Delphi mitgeliefert wird ist vieles besser geworden bei der Suche nach Speicherlecks. Auch wenn das was mitgeliefert wird kein vollständiger FastMM4 ist. Aber kann man ja leicht austauschen (wenn nur alles so einfach wäre ^^)

Wobei ich nicht sicher bin, ob MadExcept überhaupt in die Kategorie Speichermanager fällt, denn so etwas wie den Shared Memory zwischen Anwendung und DLLs (z.B. die Verwendung von Delphi-Strings statt PChars) kann MadExcept IMHO nicht.

Also würde ich eher die Frage stellen, ob man nicht beides in einem Projekt verwenden sollte. FastMM4 im Debugmodus auf der Entwicklungsmaschine, MadExcept im Release-Modus auf der Kundenseite.

Whookie 30. Aug 2018 07:51

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Codehunter (Beitrag 1411955)
Also würde ich eher die Frage stellen, ob man nicht beides in einem Projekt verwenden sollte. FastMM4 im Debugmodus auf der Entwicklungsmaschine, MadExcept im Release-Modus auf der Kundenseite.

Genau so macht das Sinn :thumb:

Der schöne Günther 30. Aug 2018 08:00

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Also mir wäre da spontan etwas unwohl - Wer garantiert mir dass die sich unter jeden Umständen gleich erhalten? Und wenn sie es täten - Warum sollte ich dann überhaupt zwei unterschiede Speichermanager einsetzen?

API 30. Aug 2018 08:04

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Der schöne Günther (Beitrag 1411974)
Also mir wäre da spontan etwas unwohl - Wer garantiert mir dass die sich unter jeden Umständen gleich erhalten? Und wenn sie es täten - Warum sollte ich dann überhaupt zwei unterschiede Speichermanager einsetzen?

Ich denke die Frage sollte im http://forum.madshi.net/ Forum gestellt werden. madshi (also der Entwickler) ist da der Experte. Zudem ist MadExcept primär für den Enduser gedacht. Also um Bug-Reports dem Entwickler der Software zu übermitteln.

Ghostwalker 30. Aug 2018 08:34

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Der schöne Günther (Beitrag 1411974)
Also mir wäre da spontan etwas unwohl - Wer garantiert mir dass die sich unter jeden Umständen gleich erhalten? Und wenn sie es täten - Warum sollte ich dann überhaupt zwei unterschiede Speichermanager einsetzen?

FastMM ist eine Speichermanager (letztlich der der standardmäßig von Delphi genutzt wird, wenn auch in abgespekter Form).

MadExcept ist ein Bibleothek/Komponente die Fehler/Exceptions behandelt, und dem (End)User die Möglichkeit bietet, das ganze dem Entwickler zu schicken (incl. einiger Systeminformationen u.a. auch Speicherinfos.)

Das sind also zwei vollkommen unterschiedliche paar Schuhe. :)

Da MadExcept (soweit ich weiß) mit Delphi entwickelt wird, sollte das ganze homogen abgehen. :)

API 30. Aug 2018 08:39

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Ghostwalker (Beitrag 1411986)
Da MadExcept (soweit ich weiß) mit Delphi entwickelt wird, sollte das ganze homogen abgehen. :)

Ja, sind wir mit Delphi entwickelt.

Das ist auch gut zu wissen:
Zitat:

Zitat von madshi
FWIW, madExcept does not contain a memory manager, unless you activate the "active error search" options on the first tab of the settings dialog. Only for those options madExcept overwrites the memory manager with its own, so it can report leaks and buffer overruns to you. These features are meant to be used mainly on your development PC, though. So for the end user, madExcept does not have a specific memory manager. For that it might still make sense to use FastMM4. Newer BCB versions automatically use FastMM4, though, IIRC.

madExcept enthält keinen Speichermanager, es sei denn, die Option "aktive Fehlersuche" wird auf der ersten Registerkarte des Einstellungsdialogs aktiviert. Nur für diese Optionen überschreibt madExcept den Speichermanager mit seinen eigenen, so dass er dir Leacks und Pufferüberläufe melden kann. Diese Funktionen sind jedoch hauptsächlich für den Einsatz auf deinem Entwicklungs-PC gedacht. Für den Endbenutzer hat madExcept also keinen speziellen Speichermanager. Aus diesem Grund könnte es trotzdem sinnvoll sein, FastMM4 zu verwenden. Neuere BCB-Versionen verwenden jedoch automatisch FastMM4, IIRC.

(http://forum.madshi.net/viewtopic.ph...=fastmm#p50532)

Codehunter 30. Aug 2018 09:18

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Damit wäre ja erstmal die Eingangsfrage beantwortet: MadExcept ist in dem Sinne gar kein Speichermanager, jedenfalls nicht einer der auf Performance ausgelegt wäre. Also sehe ich MadExcept sinnvollerweise in Alpha- und Beta-Releases beim Kunden eingesetzt, FastMM4 auf der Entwicklungsmaschine und FastMM (ohne "4", der bei Delphi mitgelieferte) in der fertigen Software. Da wärens der Möglichkeiten sogar schon drei :-D

Uwe Raabe 30. Aug 2018 09:28

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Ich muss zugeben, daß ich das active error search in madExcept noch nie benutzt habe - eben weil diese Funktionalität bereits in FastMM verfügbar ist. Trotzdem würde ich auf madExcept niemals verzichten - ebenso wenig auf FastMM (bzw. bei Performance-Problemen eine Alternative). Beides sind für mich unverzichtbare Tools in der Programmentwicklung, jedes mit einem eigenen Schwerpunkt. Der geringfügige Überschneidungsbereich beeinflusst in keiner Weise die Entscheidung für oder gegen eines der Produkte.

Codehunter 30. Aug 2018 09:33

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.

Whookie 30. Aug 2018 09:40

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Codehunter (Beitrag 1411995)
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.

Ja, funktioniert problemlos.

Lemmy 30. Aug 2018 10:57

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Codehunter (Beitrag 1411995)
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.

ich hatte damit noch nie ein Problem...

Uwe Raabe 30. Aug 2018 11:42

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Codehunter (Beitrag 1411995)
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.

Ja, das geht ohne Probleme. Wie gesagt aktiviere ich den madExcept Leak-Check aber nicht. Damit wird dann auch kein zweiter Memory-Manager eingebunden.

Stevie 30. Aug 2018 12:07

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
madExcept hat auch Handle Leak Erkennung, aber das hab ich damals in unserer großen Anwendung nicht richtig zum Laufen bekommen.

Wir benutzen madExcept, um unbehandelte Fehler abzufangen und anzuzeigen (auch in Release Builds) und FastMM mit FullDebug für Debug Builds während der Entwicklung.
Außerdem werden unsere Unittests mit Leakcheck laufen gelassen, was eine noch genauere Diagnose bietet als FastMM (z.B. graphische Darstellung von zirkulären Abhängigkeiten).

Codehunter 30. Aug 2018 13:09

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Das erste Mal das ich auf MadExcept in freier Wildbahn gestoßen bin, war bei HeidiSQL. Da fand ich das schon sehr spannend, dass man bei einer Exception die Anwendung fortsetzen konnte. Das hat in ungefähr 80% aller Fälle geklappt, sodass man noch die Chance hatte das ein oder andere zu speichern bevor das Ganze dann doch final abgeraucht ist. Ich schätze ich werde mir MadExcept denn auch demnächst mal genauer anschauen. So denn Zeit ist :roll:

freimatz 4. Sep 2018 17:23

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von ngott2 (Beitrag 1411939)
Hallo,
gibt es neben den Vorteil, das man bei MadExcept direkt zur Zeile springen kann weitere Vorteile, die für Madexcept sprechen? Oder gibt es sogar Nachteile? Wichtig nur Vorteile, die auf das finden und fixen von Speicher Leaks bezogen sind. Gerne auch eventuelle Nachteile.

Danke und Gruß.

Auch wenn meine Vorredner überwiegend richtiges schreiben halte ich die Schlussfolgerung für falsch, dass madexcept für die Suche nach Memory Leaks nicht so gut ist.
Ich halte madExcpt für das Finden von Memory-Leaks für wesentlich besser. Der Punkt ist der, dass ich bei dem für jedes Leak einen kompletten Stacktrace der Erzeugung bekomme. Das ist extrem wichtig wenn eine Klasse oder String leakt die an meheren Stellen im Programm erzeugt werden. Bei FastMM bekommt man nur die Info was und wie oft leakt, nicht aber wo. Da nehme ich die Langsamkeit bei der Analyse gerne in kauf.
Andererseits ist die Frage überflüssig, denn madExcept ist auch aus anderen Gründen einfach unverzichtbar. Und da man es schon hat, kann man es auch einfach mal ausprobieren.

Ghostwalker 5. Sep 2018 05:17

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Öhm...also...den Stack bekomm ich auch bei FastMM4

Auszug:
Code:
A memory block has been leaked. The size is: 36

This block was allocated by thread 0x3230, and the stack trace (return addresses) at the time was:
4070DE [System][@GetMem$qqri]
40AB9F [System][@NewUnicodeString$qqri]
40BBEF [System][@UStrSetLength$qqrr20System.UnicodeStringi]
4103B7 [System][UTF8ToUnicodeString$qqrrx29System.%SmallString$uc$i255$%]
4FEE7E [Vcl.Graphics][Graphics.TFont.GetName]
6B42CE [VTEditors.Core.pas][VTEditors.Core][Core.TFontData.FromFont][255]
6D9646 [VTEditors.VTDialogs.pas][VTEditors.VTDialogs][Vtdialogs.TVTFontDialog.AfterCall][315]
6D92DF [VTEditors.VTDialogs.pas][VTEditors.VTDialogs][Vtdialogs.TVTDialogExtendedBase.Call][240]
6C9F6C [VTEditors.DialogsManager.pas][VTEditors.DialogsManager][Dialogsmanager.DialogManager.CallDialogEx][132]
6E08A8 [VTEditors.ButtonControl.pas][VTEditors.ButtonControl][Buttoncontrol.TVTButton.InternalClickHandler][232]
5246D5 [Vcl.Controls][Controls.TControl.Click]

The block is currently used for an object of class: UnicodeString
Aber wie meine Vorredner schon gesagt haben, bietet MadExcept noch einiges mehr, neben den Memoryleaks. Am besten beides einsetzen und gut. :)

Codehunter 5. Sep 2018 07:17

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Ich denke zusammenfassend kann man sagen, dass es sehr wohl funktionelle Überschneidungen gibt. Die Unterschiede liegen dann in der konzeptionellen Ausrichtung. FastMM4 entstand ja mit dem Ziel, den (damals) suboptimalen Speichermanager von Delphiprogrammen zu ersetzen. Das ist auch so gut gelungen, dass er sogar offiziell von (damals glaub ich noch) Inprise ersetzt wurde. MadExcept geht es mehr um das Abfangen von Exceptions u.ä. ohne dass ein Debugger hinten dran hängt, also in freier Wildbahn.
Zitat:

Zitat von Ghostwalker (Beitrag 1412461)
Öhm...also...den Stack bekomm ich auch bei FastMM4

Ja bei FastMM4, IMHO aber nicht bei seinem kleinen Bruder FastMM der bei Delphi mitgeliefert wird.


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:13 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz