Autor |
Beitrag |
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: So 24.09.06 20:19
hallo,
ich hab mal wieder eine neue Beta hochgeladen. Das Multiselect ist nun fast komplett implementiert (fehlt eigentlich nur noch OI bei unterschieldichen komponententypen). Es gibt eine optimierungsroutine, dei überflüssige/unerwünschte Eigenschaften löscht (konfigurierbar) und eine Laufzeitcode-generierung (interessant besonders für TurboDelphi-Nutzer). Ich habe auch einige bugs gefixt (u.a. fehlende Dropdown-Menüs in der toolbar bei Copilierung mit Delphi-Version >3).
Die Version ist auf der Beta-seite ( www.fw-web.de/dfmedit_beta.php) verfügbar. Es sind weitere Kompilierungsinformationen in der Readme.txt.
Es wäre schön, wenn sich noch Beta-Tester finden würden...
Gruß Frank
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 14:12
hi, um die sourcen zu kompilieren waren 2 änderungen nötig:
1) die .dof datei löschen
2) die datei consts.pas löschen und den eintrag im dpr file auf uses consts; ändern (die unit liegt ja bei delphi bei)
hier noch ein hinweis auf eine evtl nützliche sache die du einbauen könntest:
www.geocities.com/th...ing/kolfrmdesign.jpg
www.geocities.com/th...ing/kolfrmdesign.zip
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Di 26.09.06 14:40
0xCC hat folgendes geschrieben: | hi, um die sourcen zu kompilieren waren 2 änderungen nötig:
1) die .dof datei löschen |
musste ich bei mir nicht (mit D7 und TurboDelphi getested)
0xCC hat folgendes geschrieben: | 2) die datei consts.pas löschen und den eintrag im dpr file auf uses consts; ändern (die unit liegt ja bei delphi bei) |
mit der consts.pas steht in der readme und den eintrag in der dpr musste ich auch nicht löschen. man mus nur noch das Package von vcl30 auf vcl ändern (steht aber auch in der readme).
Was soll da genau erweitert werden (ist ja selbst nur ein form-designer, den ich nicht testen kann mangels kol). ist KOL überhaupt D3-kompatibel?
Ich überlege momentan, wie man ein plugin-system realisieren kann, welches zugriff auf das treeview gestattet. dann kann man dfmedit per plugin-dlls erweitern.
die Varianten, die ich bisher gesehen habe sind ziemlich (mir zu sehr) umfangreich...
schon irgendwelche Bugs gefunden?
Gruß Frank
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 15:02
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | hi, um die sourcen zu kompilieren waren 2 änderungen nötig:
1) die .dof datei löschen |
musste ich bei mir nicht (mit D7 und TurboDelphi getested) |
die dof verweist auf die vcl30, aber delphi erstellt selber eine passende datei mit standardeinstellungen. die meisten probleme die ich bisher hatte waren auf die doofen dofs zurückzuführen, nach dem löschen derselben ging es dann aber immer.
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | 2) die datei consts.pas löschen und den eintrag im dpr file auf uses consts; ändern (die unit liegt ja bei delphi bei) |
mit der consts.pas steht in der readme und den eintrag in der dpr musste ich auch nicht löschen. man mus nur noch das Package von vcl30 auf vcl ändern (steht aber auch in der readme). |
warum eine unit beilegen die sowieso bei delphi dabei ist ? so gibt es nur versionsschwierigkeiten. (controls wurde mit einer anderen version von consts.pas kompiliert usw)
_frank_ hat folgendes geschrieben: |
Was soll da genau erweitert werden (ist ja selbst nur ein form-designer, den ich nicht testen kann mangels kol). |
naja, halt einen grafischen formdesigner einbauen ?
_frank_ hat folgendes geschrieben: | ist KOL überhaupt D3-kompatibel? |
afaik ab D4, aber sicher bin ich mir nicht...
_frank_ hat folgendes geschrieben: | Ich überlege momentan, wie man ein plugin-system realisieren kann, welches zugriff auf das treeview gestattet. dann kann man dfmedit per plugin-dlls erweitern.
die Varianten, die ich bisher gesehen habe sind ziemlich (mir zu sehr) umfangreich...
schon irgendwelche Bugs gefunden? |
ne, das programm war mir dann doch ein wenig zu komplex (darum auch der hinweis auf die grafische variante)
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 15:06
hier mal zum testen das kompilierte bsp.
Einloggen, um Attachments anzusehen!
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Di 26.09.06 15:24
0xCC hat folgendes geschrieben: |
die dof verweist auf die vcl30, aber delphi erstellt selber eine passende datei mit standardeinstellungen. die meisten probleme die ich bisher hatte waren auf die doofen dofs zurückzuführen, nach dem löschen derselben ging es dann aber immer. |
achso, so hast du das Problem mit der vcl30 gelöst...aber in der dof-datei werden nicht nur die packages gespeichert. z.B. die Versionsnummer steht da auch, und darauf will ich nicht verzichten
Mal davon abgesehen, dass delphi imho eine dof-datei ohne laufzeitpackages erstellt, d.h. du kannst die package-Funktion nicht verwenden, wenn du delphi die dof erstellen lässt.
0xCC hat folgendes geschrieben: | warum eine unit beilegen die sowieso bei delphi dabei ist ? so gibt es nur versionsschwierigkeiten. (controls wurde mit einer anderen version von consts.pas kompiliert usw) |
die war dazu gedacht, dass fehlermeldungen auf Englisch kommen und nicht in meiner IDE-Sprache (deutsch).
0xCC hat folgendes geschrieben: | naja, halt einen grafischen formdesigner einbauen ?  |
die Vorschau (Monitor in Toolbar) hast du dir aber schon angeschaut, oder? *g* Denn da ist fast alles graphisch möglich (Positionierung, Größenänderung, neue Komponenten, Eigenschaften ändern [mittels Objektinspektor], Ausschneiden/Kopieren,...). nur die Vorschau-Variante ist nicht immer nötig. die meisten Sachen lassen sich im Treeview schneller/einfacher bearbeiten.
0xCC hat folgendes geschrieben: | _frank_ hat folgendes geschrieben: | ist KOL überhaupt D3-kompatibel? |
afaik ab D4, aber sicher bin ich mir nicht... |
dachte du möchtest KOL-Support (z.B. für Laufzeit-codegenerierung).
0xCC hat folgendes geschrieben: | ne, das programm war mir dann doch ein wenig zu komplex (darum auch der hinweis auf die grafische variante) |
siehe oben, gibt es schon, nur ich nehm die nicht immer...
Gruß Frank
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 15:49
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: |
die dof verweist auf die vcl30, aber delphi erstellt selber eine passende datei mit standardeinstellungen. die meisten probleme die ich bisher hatte waren auf die doofen dofs zurückzuführen, nach dem löschen derselben ging es dann aber immer. |
achso, so hast du das Problem mit der vcl30 gelöst...aber in der dof-datei werden nicht nur die packages gespeichert. z.B. die Versionsnummer steht da auch, und darauf will ich nicht verzichten  |
wie duz meinst...
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | naja, halt einen grafischen formdesigner einbauen ?  |
die Vorschau (Monitor in Toolbar) hast du dir aber schon angeschaut, oder? *g* |
klar, allerdings dauert es verdammt lange, bis das preview erstellt ist.
_frank_ hat folgendes geschrieben: | dachte du möchtest KOL-Support (z.B. für Laufzeit-codegenerierung). |
das wär gar nicht übel
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | ne, das programm war mir dann doch ein wenig zu komplex (darum auch der hinweis auf die grafische variante) |
siehe oben, gibt es schon, nur ich nehm die nicht immer... |
im allgemeinen sieht das prog sehr brauchbar aus, vor allem die funktion, aus ner exe das dfm auszulesen.
allerdings scheint es in der preview noch probleme mit dem markieren einzelner komponenten zu geben, manche werden erst nach 2 klicks blau umrandet, manche gar nie.
ich habe ausserdem mal einen testlauf mit fastmm4.pas (eigentlich um die geschw. zu erhöhen) gemacht, und mir wurden einige speicherlecks gemeldet.
das solltest du dir vielleicht mal ansehen.
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Di 26.09.06 16:11
0xCC hat folgendes geschrieben: |
klar, allerdings dauert es verdammt lange, bis das preview erstellt ist. |
durchaus möglich dass meine routinen nicht die schnellsten sind, für bessere Varianten bin ich offen
0xCC hat folgendes geschrieben: |
das wär gar nicht übel  |
gehen natürlich nur die infos, die sich aus der DFM definieren lassen. Dazu brächte ich aber detailierte Infos, wie das bei KOL aussehen muss.
0xCC hat folgendes geschrieben: | im allgemeinen sieht das prog sehr brauchbar aus, vor allem die funktion, aus ner exe das dfm auszulesen.
allerdings scheint es in der preview noch probleme mit dem markieren einzelner komponenten zu geben, manche werden erst nach 2 klicks blau umrandet, manche gar nie. |
hast du da ne Beispiel-DFM, wo das auftritt. Hatte das Problem noch nicht.
0xCC hat folgendes geschrieben: | ich habe ausserdem mal einen testlauf mit fastmm4.pas (eigentlich um die geschw. zu erhöhen) gemacht, und mir wurden einige speicherlecks gemeldet.
das solltest du dir vielleicht mal ansehen. |
kenne die fastmm nicht, wird vermutlich auch nicht unter d3 laufen. kanst du mir sagen wo die Speicherlecks auftreten?
Gruß Frank
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 17:54
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: |
klar, allerdings dauert es verdammt lange, bis das preview erstellt ist. |
durchaus möglich dass meine routinen nicht die schnellsten sind, für bessere Varianten bin ich offen  |
ich hab mich mal ein bischen gespielt, so 20% konnte ich schon mal rausholen - siehe geänderte sourcen im beigefügten zip (siehe PERFORMANCE)
_frank_ hat folgendes geschrieben: | hast du da ne Beispiel-DFM, wo das auftritt. Hatte das Problem noch nicht. |
main_u.dfm
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | ich habe ausserdem mal einen testlauf mit fastmm4.pas (eigentlich um die geschw. zu erhöhen) gemacht, und mir wurden einige speicherlecks gemeldet.
das solltest du dir vielleicht mal ansehen. |
kenne die fastmm nicht, wird vermutlich auch nicht unter d3 laufen. kanst du mir sagen wo die Speicherlecks auftreten?
|
FASTMM4 - einfach runterladen und in einen der bibliothekspfade reinstellen, als erste USES in deiner DPR deklarieren.
die lecks treten auf weil du die kompos des Vorschaufensters zur Laufzeit generierst, aber nicht wieder freigibst.
wenn du das Objekt kreierst, solltest du einen pointer in eine Tlist speichern, und das Objekt bei shcliessen des Fenster wieder Free'en.
Zuletzt bearbeitet von 0xCC am Di 26.09.06 19:12, insgesamt 1-mal bearbeitet
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 19:03
hab noch ein bischen rumexperimentiert, diesmal ists spürbar schneller.
allerdings wird ungefähr 90% der cpuzeit mit der funktion TTreeView.GetAbsoluteIndex (und in weiterer folge GetLastChild) vertrödelt. Die Generierung deines Memo-textes per TreeView ist äusserst ungünstig, besser wäre die erstellung über eine unsichtbare verkettete liste.
Einloggen, um Attachments anzusehen!
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Di 26.09.06 19:12
sehe grade du nimmst noch die stable 2.0.0, richtig. weil in den Betas hab ich schon auf eine andere Sizing-Kompo umgestellt. aber ich schau mir die änderungen mal an...
- in der Main.pas hast du die Aktualisierungsrate der progreesbar runtergenommen, ist sinnvoll bei großen DFMs, aber bei kleinen wird imho zuviel übersprungen. evtl. muss diese berechnung in die generate-procedure. die callback wird von dort aufgerufen.
mal eine Änderung von mir:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| pStep:=Treeview.Items.Count div 100; pNext:=pStep; while ... if (isObject(tn)) and (assigned(callback)) and (tn.AbsoluteIndex>pNext) then begin callback((100*tn.AbsoluteIndex) div treeview.items.count,''); inc(pNext,pStep); end; |
so wird die callback nur bei jedem prozentpunkt einmal aufgerufen, was auch ein Geschwindigkeitsvorteil sein sollte.
- das mit dem inline/inherited ist interessant...bringt das wirklich so viel performance? eigentlich würde das erste Zeichen doch reichen...
- mit temp (lowercase) ist klar...
- so wie ich das sehe werden myTrim und somit needsTrim nicht verwendet
- fastmm funktioniert erst ab d4 evtl. kannst du mir die stellen sagen, wo speicherlecks entstehen.
du meinst doch mit Erstellen das nachträgliche Erstellen von Komponenten, "Objekt hinzufügen", oder?
Gruß Frank
Einloggen, um Attachments anzusehen!
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 19:20
jeder zugriff auf das TreeView Objekt kostet viel Zeit, speicher doch öfters verwendete properties in einer variable, z.b:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9:
| X := Treeview.Items.Count; pStep:=X div 100; pNext:=pStep; while ... if (isObject(tn)) and (assigned(callback)) and (tn.AbsoluteIndex>pNext) then begin callback((100*tn.AbsoluteIndex) div X ,''); inc(pNext,pStep); end; |
das mit dem inline bringt nicht sooo viel, weil die proc nur ca. 100 mal aufgerufen wird, die zugriffe auf das TTreeView gehen aber in die tausende. ansonsten würde es schon viel bringen, weil nicht jedesmal mit COPY ein neuer string alloziert werden muss....
die dauernden trims könnte man auch vermeiden indem man die vorhergehende copy-funktion genauer arbeiten lässt - bei jedem durchlauf eine string-alloziierung erspart.
die genauen stellen der speicherlecks kenne ich nicht, fastmm meldet nur dass welche da sind, aber nicht an welcher codestelle sie entstanden sind.
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Di 26.09.06 20:18
0xCC hat folgendes geschrieben: | jeder zugriff auf das TreeView Objekt kostet viel Zeit, speicher doch öfters verwendete properties in einer variable, z.b:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9:
| X := Treeview.Items.Count; pStep:=X div 100; pNext:=pStep; while ... if (isObject(tn)) and (assigned(callback)) and (tn.AbsoluteIndex>pNext) then begin callback((100*tn.AbsoluteIndex) div X ,''); inc(pNext,pStep); end; |
das mit dem inline bringt nicht sooo viel, weil die proc nur ca. 100 mal aufgerufen wird, die zugriffe auf das TTreeView gehen aber in die tausende. |
treeview.items.count wird genau 101x verwendet 1x beim start und bei jedem prozentpunkt 1x => so viel ist das doch nicht, oder?
0xCC hat folgendes geschrieben: | ansonsten würde es schon viel bringen, weil nicht jedesmal mit COPY ein neuer string alloziert werden muss.... |
auf welche stelle bezihst du dich da, den leerstring oben?
0xCC hat folgendes geschrieben: | die dauernden trims könnte man auch vermeiden indem man die vorhergehende copy-funktion genauer arbeiten lässt - bei jedem durchlauf eine string-alloziierung erspart.
die genauen stellen der speicherlecks kenne ich nicht, fastmm meldet nur dass welche da sind, aber nicht an welcher codestelle sie entstanden sind. |
schon klar, aber tritt der fehler immer auf oder nur wenn du im preview componenten anlegst?
die weiteren Änderungen von dir werde ich mir mal anschauen (wegen Tstrings).
mit unsichtbarer verketteter liste meinst du sicher, ich soll das treeview von seiner hierarchie unsichtbar nachbauen? glaube, das ist im moment bisschen viel Arbeit.
Gruß frank
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Di 26.09.06 20:45
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | das mit dem inline bringt nicht sooo viel, weil die proc nur ca. 100 mal aufgerufen wird, die zugriffe auf das TTreeView gehen aber in die tausende. |
treeview.items.count wird genau 101x verwendet 1x beim start und bei jedem prozentpunkt 1x => so viel ist das doch nicht, oder? |
doch, es wird pro durchlauf einmal zu oft verwendet. am besten wäre es sogar den wert per parameter an die funktion zu übergeben, dann muss sie im ganzen programmablauf nämlich nur einmal aufgerufen werden.
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | ansonsten würde es schon viel bringen, weil nicht jedesmal mit COPY ein neuer string alloziert werden muss.... |
auf welche stelle bezihst du dich da, den leerstring oben? |
ich beziehe mich auf das if copy(s,1,6) = 'inside' oder so ähnlich
_frank_ hat folgendes geschrieben: |
schon klar, aber tritt der fehler immer auf oder nur wenn du im preview componenten anlegst? |
nein, das leck tritt auf sobald ein preview angezeigt (erstellt) wird.
_frank_ hat folgendes geschrieben: | die weiteren Änderungen von dir werde ich mir mal anschauen (wegen Tstrings).
mit unsichtbarer verketteter liste meinst du sicher, ich soll das treeview von seiner hierarchie unsichtbar nachbauen? glaube, das ist im moment bisschen viel Arbeit. |
musst du nicht nachbauen, guck dir mal diese komponente an:
www.delphi-gems.com/VirtualTreeview/VT.php
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Mi 27.09.06 12:07
0xCC hat folgendes geschrieben: |
doch, es wird pro durchlauf einmal zu oft verwendet. am besten wäre es sogar den wert per parameter an die funktion zu übergeben, dann muss sie im ganzen programmablauf nämlich nur einmal aufgerufen werden. |
hab das ausprobiert (nur einmal Treeview.items.count am anfang bei zuweisung zu Integer-var), bringt nicht wirklich einen Unterschied in der performance
0xCC hat folgendes geschrieben: | ich beziehe mich auf das if copy(s,1,6) = 'inside' oder so ähnlich |
mhm...meinst, ich soll auf i am anfang prüfen und einmal copy bis zum leerzeichen (oder festwert) machen, statt 2x copy?
0xCC hat folgendes geschrieben: | nein, das leck tritt auf sobald ein preview angezeigt (erstellt) wird. |
füge mal
Delphi-Quelltext 1:
| if assigned(Comp) then freeandnil(comp); |
direkt nach der while-schleife in Generate ein. ist die einzige Stelle, die mir einfällt, wo ein solches Leck entstehen könnte (letzter durchlauf, nachdem tn=nil ist)
VirtualTreeview ist mir ein Begriff, jedoch gibts das erst ab D5 (oder D4? jedenfalls nicht für D3)
Ansonsten hat das umschreiben auf string (statt Stringlist) und die inline-sache in meiner Test-DFM ~7800 Zeilen knapp 13 sek (35 vs. 22) herausgeholt. Ist schonmal ganz gut  Danke
musste es nur selbst implementieren, da du noch die 0.2.0.0 verwendet hast, ich bereits bei der 0.2.0.8 bin.
hab die aktuelle mal angehängt...
Gruß Frank
Zuletzt bearbeitet von _frank_ am Do 28.09.06 13:48, insgesamt 1-mal bearbeitet
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Mi 27.09.06 17:19
so, ich erklär dir das mal mit der inline-sache:
du hattest:
Delphi-Quelltext 1:
| if copy(tn.Text,1,2)<>'On' then |
hier wird bei jedem durchlauf ein neuer string erzeugt, und überprüft ob er 'On' ist
ich habe draus folgendes gemacht
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17:
| function isCharAtPos(s:pchar; c:char; p: integer):boolean; begin result := false; if (p = 0) or (s=nil) then exit; inc(s,p-1); if not IsBadReadPtr(s,1) then begin if s^ = c then result := true; end; end;
function isFirstChar(s:pchar; c:char):boolean; begin result := isCharAtPos(s,c,1); end;
... if not ((isFirstChar(pchar(tn.Text),'O')) and (isCharAtPos(pchar(tn.Text),'n',2))) then |
ich überprüfe, ob das erste zeichen des BESTEHENDEN strings 'O' ist, und ob das zweite 'n' ist.
das resultat wird direkt über ein cpu-register (EAX) zurückgeliefert, erfordert also keinerlei speicher-alloziierung
alles in allem werden hier vielleicht 20 cpu-befehle durchgeführt, bei deiner variante weit über 1000.
bei einer schleife, die einige hundert mal läuft, kann man dabei bereits einen beträchtlichen geschw. unterschied feststellen.
oder bei der inline-geschichte:
du hattest:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7:
| if (copy(s,1,1)='i') then begin if copy(s,1,6)='inline' then s:='object'+copy(s,7,length(s)-6); if copy(s,1,9)='inherited' then s:='object'+copy(s,10,length(s)-9); end; |
ich hingegen:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7:
| if (isFirstChar(pchar(s),'i')) and IsCharAtPos(pchar(s),'n',2) then begin if copy(s,1,6)='inline' then s:='object'+copy(s,7,length(s)-6); if copy(s,1,9)='inherited' then s:='object'+copy(s,10,length(s)-9); end; |
ich hoffe du hast es nun verstanden, um das ganze besser nachvollziehen zu können setze einen breakpoint an der betreffenden stelle und wenn dieser erreicht wird, drücke STRG-ALT-C für das CPU fenster. mit F7 kannst du dann mit einzelschritten durchsteppen und siehst wieviele schritte die cpu ausführt, bis die fogende delphi-quelltext-zeile erreicht wird....
ich habe noch ein paar verbesserungen eingebaut, siehe attachment, der code ist noch gut 20% schneller als die letzte version
übrigens: das problem mit dem speicherleck existiert in der aktuellen version nicht mehr.
// nachtrag, nein, ich habe nur auf die fastmm4.pas vergessen, ich hänge dir noch das logfile an
vielleicht solltest du dir wirklich mal überlegen auf einen moderneren compiler zu wechseln, die D7 Personal ist eh Freeware
Einloggen, um Attachments anzusehen!
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Do 28.09.06 12:55
0xCC hat folgendes geschrieben: | so, ich erklär dir das mal mit der inline-sache: |
heist das "inline" oder meinst du nur den stringvergleich mit 'inline'?
0xCC hat folgendes geschrieben: | du hattest:
Delphi-Quelltext 1:
| if copy(tn.Text,1,2)<>'On' then |
hier wird bei jedem durchlauf ein neuer string erzeugt, und überprüft ob er 'On' ist |
ist klar...
0xCC hat folgendes geschrieben: | ich habe draus folgendes gemacht
Delphi-Quelltext
ich überprüfe, ob das erste zeichen des BESTEHENDEN strings 'O' ist, und ob das zweite 'n' ist. |
byteweiser vergleich (um keinen longstring=pointer zu bekommen?), wenn ich das richtig sehe...
0xCC hat folgendes geschrieben: | das resultat wird direkt über ein cpu-register (EAX) zurückgeliefert, erfordert also keinerlei speicher-alloziierung
alles in allem werden hier vielleicht 20 cpu-befehle durchgeführt, bei deiner variante weit über 1000. |
ohne speicherallozierung, pointer, stack, etc. ist klar, wenn alles in den registern abläuft...
0xCC hat folgendes geschrieben: | bei einer schleife, die einige hundert mal läuft, kann man dabei bereits einen beträchtlichen geschw. unterschied feststellen.
oder bei der inline-geschichte:
|
aso, mit pchar holt man sich nur die speicheradresse...dachte da wird ein neuer string angelegt (+#0) und dessen adresse zurückgegeben...
hab die 3 fälle (on, inline, >) mal so geändert, aber schneller ist es noch nicht geworden...
0xCC hat folgendes geschrieben: | ich hoffe du hast es nun verstanden, um das ganze besser nachvollziehen zu können setze einen breakpoint an der betreffenden stelle und wenn dieser erreicht wird, drücke STRG-ALT-C für das CPU fenster. mit F7 kannst du dann mit einzelschritten durchsteppen und siehst wieviele schritte die cpu ausführt, bis die fogende delphi-quelltext-zeile erreicht wird.... |
naja, bin nicht so der profi in ASM somit kann ich mit dem CPU-Fenster (gibts in D3 eh nicht (zumindest nicht im menü gefunden), strg+alt+C ist imho auch schlecht gewählt)
0xCC hat folgendes geschrieben: | ich habe noch ein paar verbesserungen eingebaut, siehe attachment, der code ist noch gut 20% schneller als die letzte version
|
werd ich mir mal anschauen...danke erstmal...
treeview1.visible => bringt nur ~60ms
@problem mit dem speicherleck
naja, viel kann ich dem nicht entnehmen...les ich das richtig, dass das Speicherleck vom Typ TCellOptions ist? sind das soviele speicherlecks? (~122 á 12b)?
TCellOptions ist für den Objectinspector, enthält infos für das Stringgrid (Datentyp der eigenschaft pPropdata). Aber so viele Eigenschaften sind doch da pro durchlauf eigentlich nicht drin...
Probier mal folgendes und sag mal bitte, ob das speicherleck dann Weg ist:
Delphi-Quelltext 1: 2: 3: 4:
| procedure TForm_DFMInspector.FormDestroy(Sender: TObject); begin freeObjects; end; |
TCellOptions werden im GetPropValues erstellt, davor werden aber evtl. existierende freigegeben (bevor an dem Stringgrid irgendwas gemacht wird).
Wichtig für multiselect (unterschiedliche Typen):
Delphi-Quelltext 1: 2: 3: 4:
| procedure TForm_DFMInspector.SetOIOnlySize; begin freeObjects; ... |
0xCC hat folgendes geschrieben: | vielleicht solltest du dir wirklich mal überlegen auf einen moderneren compiler zu wechseln, die D7 Personal ist eh Freeware |
die personal hab ich schonmal draufgehabt, aber irgendwie lief die net so toll (und vcl-code fehlt, logisch bei freeware)...evtl. probier ichs nochmal, ändert aber an der tatsache nichts, dass dfmedit in d3 (bzw. d3 kompatibel) bleibt
die geänderte ist wieder auf der beta-seite verlinkt.
ist nur noch das treeview (items.count) offen, ist der Unterschied wirklich so extrem, dass sich der Umbau wirklich lohnt?
Gruß Frank
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Do 28.09.06 15:02
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | so, ich erklär dir das mal mit der inline-sache: |
heist das "inline" oder meinst du nur den stringvergleich mit 'inline'? |
ich meine den vergleich mit 'inline' usw.
_frank_ hat folgendes geschrieben: | 0xCC hat folgendes geschrieben: | du hattest:
Delphi-Quelltext 1:
| if copy(tn.Text,1,2)<>'On' then |
hier wird bei jedem durchlauf ein neuer string erzeugt, und überprüft ob er 'On' ist |
ist klar...
0xCC hat folgendes geschrieben: | ich habe draus folgendes gemacht
Delphi-Quelltext
ich überprüfe, ob das erste zeichen des BESTEHENDEN strings 'O' ist, und ob das zweite 'n' ist. |
byteweiser vergleich (um keinen longstring=pointer zu bekommen?), wenn ich das richtig sehe... |
nein, damit kein neuer string alloziiert wird...
_frank_ hat folgendes geschrieben: | hab die 3 fälle (on, inline, >) mal so geändert, aber schneller ist es noch nicht geworden... |
ich weiss mindestens 4 fälle (auch das mit '='), aber ich habe die änderungen bereits in die 0.2.0.8 eingebaut.
warum nimmst du nicht einfach meinen source (die stelle mit dem perf-counter kannst ja auskommentieren) ?
bei mir dauert es nun bei main_u.dfm statt 1,31 sek 1,11 sek
_frank_ hat folgendes geschrieben: |
werd ich mir mal anschauen...danke erstmal... |
nicht anschauen, einbauen
_frank_ hat folgendes geschrieben: | treeview1.visible => bringt nur ~60ms |
na, immerhin - schneller ist besser
_frank_ hat folgendes geschrieben: | @problem mit dem speicherleck
naja, viel kann ich dem nicht entnehmen...les ich das richtig, dass das Speicherleck vom Typ TCellOptions ist? sind das soviele speicherlecks? (~122 á 12b)? |
nein, es gibt mehrere -> siehe screenshot (vermutlich eines für jede erzeugte kompo der preview (gilt alles für main_u.dfm)
_frank_ hat folgendes geschrieben: | ist nur noch das treeview (items.count) offen, ist der Unterschied wirklich so extrem, dass sich der Umbau wirklich lohnt?
|
der umbau lohnt, da ich ihn doch bereits für dich vorgenommen habe.
installier dir halt das D7 Pers noch dazu und mach da deine Lecktests.
ich hab auch mehrere delphi-versionen installiert.
Einloggen, um Attachments anzusehen!
|
|
_frank_ 
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Do 28.09.06 16:07
0xCC hat folgendes geschrieben: |
ich weiss mindestens 4 fälle (auch das mit '='), aber ich habe die änderungen bereits in die 0.2.0.8 eingebaut.
warum nimmst du nicht einfach meinen source (die stelle mit dem perf-counter kannst ja auskommentieren) ?
bei mir dauert es nun bei main_u.dfm statt 1,31 sek 1,11 sek |
weil ich das selber einbauen will  , da verstehe ich die Änderungen besser bzw. kann ich mir die auch besser merken...
0xCC hat folgendes geschrieben: | nein, es gibt mehrere -> siehe screenshot (vermutlich eines für jede erzeugte kompo der preview (gilt alles für main_u.dfm) |
0xCC hat folgendes geschrieben: | der umbau lohnt, da ich ihn doch bereits für dich vorgenommen habe.
installier dir halt das D7 Pers noch dazu und mach da deine Lecktests.
ich hab auch mehrere delphi-versionen installiert. |
hab mir die personal mal installiert und bekomme die fehlermeldung "für den Zugriff auf 'isMultiThead' von Unit FastMM4 wird die Referenz auf importierte Daten ($G) benötigt".
im Projektquellcode kann ich $G nicht setzen ({$G+} am anfang), mach ich das in der Main_u.pas bleibt der Fehler. in den Projektoptionen finde ich nichts mit "Importierte Daten".
Wie bekomme ich den Fehler weg?
ein paar speicherlecks (TTypeObject) müssten sich so entfernen lassen:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26:
| procedure FreeSLObjects(list:TStrings); var i:integer; begin for i:=0 to list.Count-1 do if assigned(list.Objects[i]) then begin list.Objects[i].free; list.Objects[i]:=nil; end; end; procedure GetComponentProps(AComponent:string;List:TStrings;AppendSubclasses:boolean); var ... begin FreeSLObjects(list); list.clear;
procedure TForm_DFMAdd.FormDestroy(Sender: TObject); begin FreeSLObjects(cb_Name.Items); FreeSLObjects(cb_SubClass.Items); end; |
Gruß Frank
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
Zuletzt bearbeitet von _frank_ am So 24.06.07 15:19, insgesamt 1-mal bearbeitet
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Do 28.09.06 18:12
_frank_ hat folgendes geschrieben: |
hab mir die personal mal installiert und bekomme die fehlermeldung "für den Zugriff auf 'isMultiThead' von Unit FastMM4 wird die Referenz auf importierte Daten ($G) benötigt".
im Projektquellcode kann ich $G nicht setzen ({$G+} am anfang), mach ich das in der Main_u.pas bleibt der Fehler. in den Projektoptionen finde ich nichts mit "Importierte Daten".
Wie bekomme ich den Fehler weg? |
vermutlich direkt in der fastm4.pas setzen
|
|
|