Allgemeine Fragen zur PROFAN Programmierung
Views (Heute): 249534 (10970)
  Suchen
 Zurück zur Übersicht
 AutorThema: Profan Hackt mal wieder --> Speicherleck !!!
Thorsten.HG
Datum:01.08.01 21:46 Antwortenals Email verschicken (galaxy@mrk-soft.de) 


Hi,

Auch wenn einige immer wieder behaupten, das
es diesen Fehler nicht gebe, oder die Schuld
immer auf die externen DLL aufschieben, nun
hab ich ihn wieder, den Fehler im Speicher
und das Profan immer langsmamer wird, bei der
Programmausführung !!!! (Profan 7.0e)

Eingrenzung: Der Fehler tritt hier immer dann
auf, wenn ich externe DLL's anspreche.

Pänomen1: Das Programm läuft mit z.b 30 Zeilen
ohne Probleme und schnell. Werden es
nun mehr als diese 30, dann wird
das Programm auf einmal so langsamm,
(über 90 %), das nichts mehr geht.

Egal, was es für zeilen sind, selbst
REM oder Kommentar-Zeilen rufen
dieses Phänomen zu Tage.

Phänomen2: wird heufig eine DLL-Funktion dann
aufgerufen, die obiges Problem
aufweist, scheint auch plötzlich der
Speicher zu schwinden !!!

Roland, ich weiss, das du das nicht nicht
unbedingt nachvollziehen kannst, falls du
den Quellcode, der das Problem bisher hat,
haben möchtest, so kann ich ihn die gerne
zusenden.

Meine Vermutung:

Bei der Verwarwaltung von DLL's über DEF
scheint wohl noch etwas gravirendes zu sein,
den entfernen ich alle ext. dlls so ist der
Fehler plötzlich verschwunden !!!

Fazit:

damals zu Profan 4.5 (16 BIT) Zeiten waren
aufrufe von dlls unheimlich langsamm, (mehrere
aufrufe brachten den Rechner zum Schlafen).

als ich dich damals daeaufhin anrief, sagteste,
das dieser Fehler in 5.0 behoben sei !!!
unter 5.0, 16 Bit lief das dann auch soweit
ohne fehler, nur fing dann plötzlich das
Problem an, das ab einer bestimmten Zeilenlänge
das Programm aufeinmal 90 % langsammer war
als normal, so, also ob bei jedem Zyxlus Profan
da den Kompletten Speicher durchakert,
durchzählt oder sonst was macht.

Sporalisch tauchte der Fehler auch unter 5.0,
6.0, 6.5 auf (32 bit), dachte mir aber nichts
dabei. Nun unter 7.0 ist und Intensieves
Ansprechen von Ext. DLLs ist der Fehler wieder
da ...

Achja, das es an den DLLs liegt, und das diese
das Problem seine, nenene, den Zahn könnt ihr
euch ziehen, den:

a) 2 der DLLs, die diesen Fehler unter Profan
7.0(e) verursachen, laufen unter VB bzw.
Pascall ohne Probleme. Und einen einfachen
aufruf

GetTemp (
comport as integer)

Rückgabewert: Long als Temp.Wert

werd ich wohl noch in Profan als

DEF GetTemp !"tempio.dll","GetTemp"
Wert& = GetTemp($3F8)

umsetzen können.

Thorsten

ps: Roland, eigentlich müsten alle, die diesen
Fehler nachweisslich aufzeigen können,
7.5 kostenlos bekommen, wenn dort der
Fehher mal behoben !!! sein sollte ....




Frank Abbing
Datum:02.08.01 13:17 Antwortenals Email verschicken (frankabbbing@12move.de) 


Hallo,

ich habe bei mir auch hin und wieder solche Verzögerungen bemerkt, allerdings nicht bis zu 90%, aber bestimmt um die 50%.
Mit Dll's hab' ich sie aber bisher nicht in Verbindung gebracht. Allerdings vorher, mit Profan 4.5 hatte ich die Probleme nicht, dort hatte ich auch nie mit Dll's gearbeitet.
In letzter Zeit hatte ich aufgrund meiner ProSpeedDLL des öfteren Testprogramme und Beispielprogramme laufen, manchmal ging die Geschwindigkeit arg in den Keller. An der Dll liegt's nicht. Die meisten Funktionen benutzen nur reinen Assemblercode, da geht keine Geschwindigkeit verloren !!!
Irgendwas ist da faul im Staate Dänemark, und wenn andere das auch bemerkt haben, wird wohl was dran sein...

Bis dahin,

Frank


Roland G. Hülsmann
Datum: 05.08.01 23:34 Antwortenals Email verschicken (rgh-soft@t-online.de) 


Hallo!
Schicke mir doch bitte mal ein (möglichst kurzes) Programm, wo dieses Problem auftritt. Bitte ggf. die benötigte DLL mit dazulegen, damit ich es ausprobieren kann. Alles in eine ZIP-Datei packen und an meine eMail-Adresse. Danke.

Hast Du auch ausprobiert, ob es bei den anderen Möglichkeiten, DLL-Funktionen aufzurufen, die gleichen Probleme gibt? Mit @EXTERNAL oder über eine Headerdatei.

In allen drei Fällen ist es bei widerholtem Aufruf der gleichen externen DLL-Funktion (auch bei DEF) zur Temposteigerung wichtig, die DLL vorher EINMALIG mit USEDLL zu laden. Hat die DLL einen eigenen Datenhaushalt, ist dies absolut unabdingbar, damit diese Daten erhalten bleiben. In PROFAN werden die DLLs dynamisch gelinkt und nicht statisch, daher ist das USEDLL notwendig. Wird die DLL nicht zuvor mit USEDLL geladen, wird sie bei jedem Aufruf von der Platte gelesen und das kann gewaltig Tempo kosten, zumal dann, wenn der Cache nicht sehr groß ist.

Noch schlimmer wird es, wenn die DLL schlampig programmiert ist und den benutzten Speicher beim Verlassen nicht frei gibt. Ohne USEDLL könnte es dann sein, daß die DLL jedesmal Speicher beansprucht, ihn aber nie wieder freigibt. Das kann natürlich auch zu gewaltigen Performanceproblemen führen!

Also IMMER (egal wie die DLL aufgerufen wird) so vorgehen:
1. Die DLL mit USEDLL laden.
2. Die DLL-Funktionern beliebig nutzen
3. Die DLL am Programmende mit FREEDLL wieder freigeben.


 Zurück zur Übersicht