Browseraufbau in .355 langsamer als .331?

[kallecux]

Hallo Xbase-Freunde,

ich habe ein Programm, welches mehrer Tab's mit insgesamt 4 DBF-Browsern erzeugt (TopDown Browser tdHibrow(..)).

Wenn ich dieses Programm mit der .331 erzeuge, dauert das Erzeugen und Anzeigen des Dialoges ca. 2 Sekunden
Wenn ich dieses Programm mit der .355 erzeuge, dauert das Erzeugen und Anzeigen des Dialoges ca. 5 Sekunden

Kann mir evtl. jemand einen Tipp geben?

[Scarmo]

Hallo Karl Heinz

Vermutlich hängt dies mit der Unterstützung der Visual-Styles zusammen... Da wird wahrscheinlich eine Abfrage durchlaufen, welche in der 331 noch nicht drin war... Wie man dies jedoch optimieren bzw. umgehen könnte, habe ich leider keine Ahnung... Sorry!

Gruss
Marco

[kallecux]

Hallo Marco,
danke für den Tipp - per GetApplication():enableVisualStyles habe ich die VisualStyles ausgeschaltet. Die Zeit vergeht eindeutig bei der Erzeugung der Browserobjekte - offensichtlich dauern diese nun länger. Es ist "alter" Quellcode für die .331 - also ohne Spielereien!

[AUGE_OHR]

Wenn ich dieses Programm mit der .331 erzeuge, dauert das Erzeugen und Anzeigen des Dialoges ca. 2 Sekunden
Wenn ich dieses Programm mit der .355 erzeuge, dauert das Erzeugen und Anzeigen des Dialoges ca. 5 Sekunden

man muss ja jetzt immer nachfragen "welche" SL1 v355 Version "full" oder "ohne" ?

zumindest die "ohne" ist gegenüber der v350 "beta" deutlich schneller ...

[kallecux]

Hallo Jimmy,

man muss ja jetzt immer nachfragen "welche" SL1 v355 Version "full" oder "ohne" ?

was meinst Du damit? Ich habe eine Subskription - bin ich nun full?

[Manfred]

Yepp

[brandelh]

Hallo Jimmy,

man muss ja jetzt immer nachfragen "welche" SL1 v355 Version "full" oder "ohne" ?

was meinst Du damit? Ich habe eine Subskription - bin ich nun full?

das kommt drauf an, was du installiert hast !

Die neue Installation mit dem SL1 (zuerst veröffentlicht unter aktuelle Version) ist FULL,
das Patchen mit dem später erhältlichen SL1 Patch ist OHNE

[kallecux]

Danke - Danke - Danke

Nichts für ungut - aber das hat ja mit meinem Problem nichts zu tun. Es ist wirklich da!

[AUGE_OHR]

Nichts für ungut - aber das hat ja mit meinem Problem nichts zu tun. Es ist wirklich da!

JaNein ... die "schnelle" Version ist die "ohne", deshalb hat ich ja immer so darauf gedrängt

[kallecux]

Jetzt komme ich aber ins Grübeln - wie? Schnell und Langsam - bitte kläre mich auf, da ich ein echtes Performance-Problem habe.
Danke!

[Jan]

Karl Heinz,

es gibt 2 Versionen des SL1:
1) Als 1.9 + Themes (also Unterstützung von XP- und Vista-Optik)
2) Wie 1), aber zusätzliche neue Funktionen

1) ist nur für User mit laufender 1.9, 2) für User mit aktiver Subscription

Ich selber arbeite mit 2), habe aber bislang keine Geschwindigkeitsprobleme feststellen können. Auch nicht mit mehreren tausend Datensätzen im Browse. Ich arbeite aber auch mit Xbase++ pur, ohne 3rd party tools.

Es gibt da von Hannes eine Anleitung, wie man große Browses anzeigt ohne Zeitverzögerung. Ich muß das mal raussuchen. Er macht das über 2 parallel laufende Threads, der eine zeigt das schon mal gefundene an, der andere sammelt im Hitergrund weiter.

Jan

[brandelh]

Hallo,

Jimmy hat wohl festgestellt, dass sich einige Controls unter den verschiedenen .355 Versionen (Neuinstallation SL1 bzw. PATCH von .331) verschieden verhalten, genauer habe ich das jetzt auch nicht verstanden ... ich persönlich habe "noch" keine Probleme, solange sich die Controls nicht überschneiden ---> :clipsiblings - Einstellung.

Die Performance Probleme könnten daher kommen, dass das neue XbpBrowse eventuell mehr arbeiten muss,
aber ich vermute eher "tiefere Probleme". Hast du dein Programm in der gleichen Umgebung verschieden kompiliert und beide Messungen durchgeführt ?

Versuche mal mit den Einstellungen (mit / ohne Manifest Datei) und visual Styles die verschiedenen Kombinationen durch
und auch ob die Laufzeiten immer gleich oder sehr unterschiedlich sind.
Hast du einen neuen Virenscanner ? Dort sollte man auf jeden Fall *.NTX, *.CDX, *.DB* von der Überprüfung ausschließen.

PS: und natürlich alle Indexe neu erzeugt ?

[kallecux]

Hallo Jan, hallo Hubert,

ja, ich weiß, machmal macht man seine gesamte Umgebung verrückt weil man glaubt "da stimmt was nicht" und in wirklichkeit ist sieht man selbst den Wald vor lauter Bäumen nicht. Aber ich habe ohne auch nur eine Zeile zu ändern, das Programm mit .355 und .331 kompiliert und das Verhalten ist unterschiedlich. Es handelt sich übrigens nicht um eine große Tabelle, sondern um 4 Tabellen, deren Erzeugungszeit sich addiert und somit von ingesamt 2 Sekunden auf 4-5 Sekunden verlängert.

Mittlerweile habe ich die Tabs raugenommen und die Objekte direkt auf der drawingArea erzeugt - ohne Erfolg. Ich habe auch schon Clayton Jones gefragt - der hat das auch noch nicht beobachtet. Ich habe es auch schon auf 3 verschiedenen Maschinen getestet...immer dasselbe. Hmm.....

[brandelh]

Was machst du denn mit den Tabellen ?
Nur anzeigen oder editieren in den Zellen ?

Ich persönlich verwende meist XbpQuickBrowse() zusammen mit den DAC... Funktionen (gepufferte Datenanzeige).
Das ist wirklich schnell, wenn ich dann was ändern muss, kopiere ich den Datensatz (bzw. die zu ändernden Felder)
in ein Erfassungsformular (kann auf dem gleichen Fenster liegen) und speichere nach Ende wieder zurück.

[kallecux]

Es sind "normale" Browse-Objekte zum Anzeigen. Und es ist nur das Problem des Erzeugens und des Anzeigens. Alles andere ist nicht relevant.

[brandelh]

... Problem des Erzeugens und des Anzeigens. Alles andere ist nicht relevant.

die komplexe Bauweise von XbpBrowse() (jede ZELLE ein eigenes Fenster, das für sich getrennt jeweils seine Daten anfordern muss ... mehrere Zeilen die Daten brauchen) und die Datenbeschaffung sind das Problem bei allen XbpBrowse()rn. Die gepufferten XbpQuickBrowse() sind einfacher aufgebaut, cachen die DBFs und verursachen viel weniger Aufwand (für den Rechner) somit sind sie schneller.

Was ist also relevanter als die Frage ob man den komplexen lahmen XbpBrowse() nicht durch einen XbpQuickBrowse() ersetzen kann ?
Warum die 355 langsamer als die 331 ist (und ob es so ist), kann ich nicht beantworten.

[AUGE_OHR]

Jetzt komme ich aber ins Grübeln - wie? Schnell und Langsam - bitte kläre mich auf, da ich ein echtes Performance-Problem habe.

ich habe die v331, v331+hotfix, v350rc1 und die v355 "ohne" und finde die v355 "ohne" am besten.

was nun XbpBrowse() (tdHibrow(..)) angeht habe ich ja unter Win7 diese Beobachtung gemacht.
a.) GFK DX9 fähig 128Mb RAM
b.) "lates" Treiber und DirectX
c.) Windows Media Player "Hardware Beschleunigung" auf default

"Performance" Test : Dia Slideshow mit *.JPG laufen lassen ...

:enableVisualStyles

XBPAPP_NOSTYLES ?
die v355 "ohne" hat das selbe "Problem" bei XbpBrowse() denn die ist nicht "visual Style free" ...

[Manfred]

Hi Jimmy,

jetzt habe ich das erst richtig gelesen. Das bedeutet, Du kennst nur die 355 ohne und die 355 mit hattest Du noch gar nicht in den Händen? Also weißt Du jetzt gar nicht, ob die 355 mit wieder langsamer als die 355 ohne ist?

[AUGE_OHR]

Also weißt Du jetzt gar nicht, ob die 355 mit wieder langsamer als die 355 ohne ist?

richtig ... aber wenn "visual Styles" aktive ist wird das ja auch noch "gemalt" also muss
die "full" einen langsameren Bildschirmaufbau haben.

Gegenprobe : unter XP mit und ohne Manifest in etwa der selbe Unterschied (1000x create/destroy)

[Manfred]

ok,

das ist nachvollziehbar. Da ich aber keine Visual Styles benutze zur Zeit....

[kallecux]

Hallo!

Ich komme langsam nicht mehr richtig mit - ich habe wohl eine "Full" und werde einen Test mit ausgeschalteten Visualstyles durchführen. Ich melde mich dann wieder.

[Jan]

Karl Heinz,

ich selber schalte für die Browses immer die Themes aus. Und nur für die Browses (denn ansich soll mein Programm ja aussehen wie die Windowsversion, auf dem das läuft).

Code: Alles auswählen

   IF IsThemeActive(.T.) == .T.
      // Die Styles für den Browser abschalten
      oBrowse:UseVisualStyle := .F.
      // Aber die Scrollbars mit Themes anzeigen
      oBrowse:hScrollObject:useVisualStyle := .T.
      oBrowse:vScrollObject:useVisualStyle := .T.
   ENDIF

Wenn die Verlangsamung wirklich durch die mitlaufenden Themes kommt: Vielleicht hilft das dann ja.

Jan

[AUGE_OHR]

Da ich aber keine Visual Styles benutze zur Zeit....

W2K oder kein Manifest ?

[AUGE_OHR]

Code: Alles auswählen

   IF IsThemeActive(.T.) == .T.
      // Die Styles für den Browser abschalten
      oBrowse:UseVisualStyle := .F.
      // Aber die Scrollbars mit Themes anzeigen
      oBrowse:hScrollObject:useVisualStyle := .T.
      oBrowse:vScrollObject:useVisualStyle := .T.
   ENDIF

Wenn die Verlangsamung wirklich durch die mitlaufenden Themes kommt: Vielleicht hilft das dann ja

auch die v355 "ohne" hat das selbe "Problem" bei XbpBrowse() denn die ist nicht "visual Style free" ...
also den Code von Jan auch in die "ohne" Version einbauen wenn man die "neue" Optik nicht mag.

ich sehe das "Problem" im Aufbau von XbpBrowse(), welche ja aus XbpColumne bestehen.
Jede "Cell" einer Columne ist eine "Innerstatic" und hat auch noch einen "Frame" und alle haben
die Property StyleClass/StylePart. Auch wenn die "Abfragen" abgeschaltet sind wird der "neue"
Code durchlaufen was man an der "ohne" Version ja merkt.

obwohl die SL1 "ohne" schneller geworden ist als die v331 ist das XbpBrowse() langsamer geworden.
wie Hubert schon sagte müsste man sich wohl mehr mit XbpQuickBrowse() beschäftigen wenn es
um Performance geht, aber leider habe ich dann weniger Möglichkeiten und muss evtl. das
Konzept umstellen.

allerdings hätte XbpQuickBrowse() auch schon "eher" was mit Windows zu tun (Listview/Datagrid)
den XbpBrowse() ist ja eigentlich nur ein "aufgebohrtes" TBrowse und der "Skipper" ist ja pro
Datensatz und erzeugt bei jeder "Bewegung" massiven Datentransfer.

wenn man eine "begrenzte" Datenmenge hat und die nur als "Auswahl" benötigt dann ist es evtl.
schneller alles in ein Array "in-einem-rutsch" einzulesen statt per "Skipper" auf ein :stable zu
warten. zusätzlich "könnte" man ja die ersten "Treffer" schon Anzeigen während er per Thread
das Array noch weiter "füllt".

ein solches Demo gibt es ja bei Alaska in der ACSN, also mal ausprobieren.

[Manfred]

XP und ohne Manifest.