AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Werkzeuge MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Thema durchsuchen
Ansicht
Themen-Optionen

MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

Ein Thema von ngott2 · begonnen am 29. Aug 2018 · letzter Beitrag vom 5. Sep 2018
Antwort Antwort
freimatz

Registriert seit: 20. Mai 2010
1.490 Beiträge
 
Delphi 11 Alexandria
 
#1

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 4. Sep 2018, 17:23
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.
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 5. Sep 2018, 05:17
Ö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.
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.283 Beiträge
 
Delphi 12 Athens
 
#3

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 5. Sep 2018, 07:17
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.
Ö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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:23 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz