Allgemeine Fragen zur PROFAN Programmierung

Views (Heute): 249534 (10970)

| Suchen
| Zurück zur Übersicht

Autor | Thema: Profan Hackt mal wieder --> Speicherleck !!!
Thorsten.HG
| Datum:01.08.01 21:46 (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 (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 (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