Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

Lahme Ausführung (Real Studio network user group Deutschland Mailinglist archive)

Back to the thread list
Previous thread: Hier ist ja richtig was los.
Next thread: Mouse Icon


Re: Re: verschiedene Fonts einzelnen Zellen in Listbox zuweisen   -  
  Lahme Ausführung   -   Frank Juling
   Re: Lahme Ausführung   -   Stephan Huber
    Re: Lahme Ausführung   -   Frank Juling
     Re: Lahme Ausführung   -   Stephan Stoske
      Re: Lahme Ausführung   -   Frank Juling

Lahme Ausführung
Date: 04.08.03 17:27 (Mon, 04 Aug 2003 18:27:10 +0200)
From: Frank Juling
Hi Leutz,

hab ein Programm geschrieben und bin mit dem Ausführungsspeed überhaupt
nicht zufrieden. Da ich noch ziemlich neu auf dem Gebiet RB bin hier nun
meine Frage: Welcher echter Auskenner würde sich mal meinen Code ansehen und
mir ein paar Tipps oder Anregungen geben was man besser machen kann oder was
grundsätzlich falsch gemacht wurde. Bin für jegliche Art von Feedback
dankbar.

Proggi läuft unter RB 5.2 / OSX (bei mir auf einem Pismo, G3 400)
download compiled App unter www.epi-dev.de/download/diropusx.sit

Den Source schick ich dann bei Interesse gesondert per mail zu.

Bin schon am verzweifeln ob RB dafür taugt oder ob es an meiner Unfähigkeit
:) liegt.

Danke im voraus,
Grüße,
Frank

Email : f.juling at epi minus dev dot de

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>

Re: Lahme Ausführung
Date: 06.08.03 10:54 (Wed, 06 Aug 2003 11:54:16 +0200)
From: Stephan Huber


--On Montag, 4. August 2003 18:27 Uhr +0200 Frank Juling <<email address removed>>
wrote:

> Bin für jegliche Art von Feedback
> dankbar.

naja, das was du da vorschlägst ist ein bisschen brute force. Dein Programm
ist reichlich komplex, da ist es nicht einfach zu sagen, was langsam ist,
und warum. Ausserdem wieß ich nicht, was du unter langsam verstehst. Du
wirst ja selber schon eine Ahnung haben, was nicht so toll performt, bzw.
es mit einfachen Zeitmessungen überprüfen, welche Sachen langsam sind, und
diese Methoden kannst du ja mal hier posten.

Es ist immer einfacher dem Problem durch Zerteilung die Komplexität zu
nehmen. Sprich, es ist viel einfacher, sich über die Effizienz einer
Routine den Kopf zu zerbrechen, als darüber, warum das alles zusammen
irgendwie langsam ist.

Für RB gibt es soweit ich mich richtig erinnere, ein paar Profiler-Klassen,
die relativ einfach einzubauen sind, und dir auf das Komma genau sagen
können, wie lange eine Routine benötigt, um sie auszuführen.

"Hier haste meinen _kompletten_ Source-Code, guck mal, was verkehrt ist",
ist extrem unsexy. ;)

Stephan

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>

Re: Lahme Ausführung
Date: 06.08.03 11:13 (Wed, 06 Aug 2003 12:13:29 +0200)
From: Frank Juling
Du hast recht, ich werde die Sache anders angehen.
Was mich aber extrem performant stört ist die langsame GUI wenn mal mehr als
10 Objekte in einem Fenster hat und darunter auch noch Listboxen sind.
Hab das Programm mal entkernt und nur reine gefüllte Objekte im Mainwindow
belassen. Keine Änderung. Das Resizen ist wirklich zäh, und ich benutze
nicht einmal liveresize.

Mit dem Sourcecode wollte ich bloß grundsätzliche Fehler aufdecken, Struktur
des Programms, Klassenbildung, Kommunikation unter den Klassen.

Danke,
Gruß,
Frank

06.08.2003 11:54 Uhr/Stephan Huber wrote

>
>
> --On Montag, 4. August 2003 18:27 Uhr +0200 Frank Juling <<email address removed>>
> wrote:
>
>> Bin für jegliche Art von Feedback
>> dankbar.
>
> naja, das was du da vorschlägst ist ein bisschen brute force. Dein Programm
> ist reichlich komplex, da ist es nicht einfach zu sagen, was langsam ist,
> und warum. Ausserdem wieß ich nicht, was du unter langsam verstehst. Du
> wirst ja selber schon eine Ahnung haben, was nicht so toll performt, bzw.
> es mit einfachen Zeitmessungen überprüfen, welche Sachen langsam sind, und
> diese Methoden kannst du ja mal hier posten.
>
> Es ist immer einfacher dem Problem durch Zerteilung die Komplexität zu
> nehmen. Sprich, es ist viel einfacher, sich über die Effizienz einer
> Routine den Kopf zu zerbrechen, als darüber, warum das alles zusammen
> irgendwie langsam ist.
>
> Für RB gibt es soweit ich mich richtig erinnere, ein paar Profiler-Klassen,
> die relativ einfach einzubauen sind, und dir auf das Komma genau sagen
> können, wie lange eine Routine benötigt, um sie auszuführen.
>
> "Hier haste meinen _kompletten_ Source-Code, guck mal, was verkehrt ist",
> ist extrem unsexy. ;)
>
> Stephan
>
> - - - - - - - - - -
> For list commands, send "Help" in the body of a message to
> <<email address removed>>
>

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>

Re: Lahme Ausführung
Date: 06.08.03 13:11 (Wed, 6 Aug 2003 14:11:09 +0200)
From: Stephan Stoske
Hi,

die Prozesskette die bei einem Refresh oder einer sichtbaren Änderung
ausgelöst
wird ist unter OSX um Größenordnungen komplexer und aufwendiger als je
zuvor,
das betrifft nicht nur REALbasic. Umso wichtiger ist es unnötige Refreshs
zu vermeiden.
Also vorher nachschauen ob eine Änderung überhaupt notig ist:

if editField.text <> neuerInhalt then
editField.text = neuerInhalt
end if

if not WasWeissIch.visible then
WasWeissIch.visible = true
end if

if neuerWert <> alterWert then
' Wert hat sich verändert
alterWert = neuerWert
end if

Wichtig ist es auch die Ereignisketten zu kennen, also welche Events
ihrerseits
welche Events aufrufen, dadurch spart man sich viel Code. Einige Anwender
rufen
z.B. im Paint-Event, beim Open des Fenstes und beim Resize eigene Methoden
auf, die dann doppelt und dreifach laufen. Aus dem gleichen Grunde sollten
im
Paint-Event überhaupt keine darstellende Funktionen liegen, denn sonst
erfolgt
nach jeder einzelnen(!) Funktion (Pixel ändern, Grafik zeichnen, Bilder
malen) ein
langwieriger Refresh.

Ein weiterer oft gemachter Fehler ist, nicht zwischen Programm- und
Anwender-
Aktion zu unterscheiden, also wenn man z.B. ein Editfeld vom Programm aus
mit
einem Wert belegt, dann wird das als Änderung des Anwenders verstanden und
löst evtl. entsprechende Methoden aus. Am Schlimmsten dann, wenn die Methode
diese Anzeige vielleicht korrigiert, was dann wieder als Änderung
verstanden wird
und eine Kettenreaktion bewirkt. Das löst man einfach mit einer ownAction-
Eigenschaft.

Im Control:
if not ownAction then
' dann reagieren, weil User-Aktion
end if

Bei Programmänderungen des Controls:
ownAction = true
' Control ändern
ownAction = false

Es gibt noch zahlreiche Dinge die es zu beachten gibt, die man schneller und
eleganter lösen könnte, aber die wenigstens davon sind wirklich RB-
spezifisch,
sie betreffen vielmehr ganz allgemein die Programmierung.

Grüße, Stephan

-------------------------------------------------------------------------
stoske & bertling - visuelle kommunikation
lohmühler berg 30 - 42553 velbert - fon 02053/504464 - fax 02053/923630
<email address removed> - www.stoske-bertling.de - ftp.stoske-bertling.de

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>

Re: Lahme Ausführung
Date: 06.08.03 14:28 (Wed, 06 Aug 2003 15:28:07 +0200)
From: Frank Juling
Ok, da hab ich erstmal genug zu tun.

Danke,
Grüße aus Berlin,
Frank

06.08.2003 14:11 Uhr/Stephan Stoske wrote

> Hi,
>
> die Prozesskette die bei einem Refresh oder einer sichtbaren Änderung
> ausgelöst
> wird ist unter OSX um Größenordnungen komplexer und aufwendiger als je
> zuvor,
> das betrifft nicht nur REALbasic. Umso wichtiger ist es unnötige Refreshs
> zu vermeiden.
> Also vorher nachschauen ob eine Änderung überhaupt notig ist:
>
> if editField.text <> neuerInhalt then
> editField.text = neuerInhalt
> end if
>
> if not WasWeissIch.visible then
> WasWeissIch.visible = true
> end if
>
> if neuerWert <> alterWert then
> ' Wert hat sich verändert
> alterWert = neuerWert
> end if
>
> Wichtig ist es auch die Ereignisketten zu kennen, also welche Events
> ihrerseits
> welche Events aufrufen, dadurch spart man sich viel Code. Einige Anwender
> rufen
> z.B. im Paint-Event, beim Open des Fenstes und beim Resize eigene Methoden
> auf, die dann doppelt und dreifach laufen. Aus dem gleichen Grunde sollten
> im
> Paint-Event überhaupt keine darstellende Funktionen liegen, denn sonst
> erfolgt
> nach jeder einzelnen(!) Funktion (Pixel ändern, Grafik zeichnen, Bilder
> malen) ein
> langwieriger Refresh.
>
> Ein weiterer oft gemachter Fehler ist, nicht zwischen Programm- und
> Anwender-
> Aktion zu unterscheiden, also wenn man z.B. ein Editfeld vom Programm aus
> mit
> einem Wert belegt, dann wird das als Änderung des Anwenders verstanden und
> löst evtl. entsprechende Methoden aus. Am Schlimmsten dann, wenn die Methode
> diese Anzeige vielleicht korrigiert, was dann wieder als Änderung
> verstanden wird
> und eine Kettenreaktion bewirkt. Das löst man einfach mit einer ownAction-
> Eigenschaft.
>
> Im Control:
> if not ownAction then
> ' dann reagieren, weil User-Aktion
> end if
>
> Bei Programmänderungen des Controls:
> ownAction = true
> ' Control ändern
> ownAction = false
>
> Es gibt noch zahlreiche Dinge die es zu beachten gibt, die man schneller und
> eleganter lösen könnte, aber die wenigstens davon sind wirklich RB-
> spezifisch,
> sie betreffen vielmehr ganz allgemein die Programmierung.
>
> Grüße, Stephan
>
> -------------------------------------------------------------------------
> stoske & bertling - visuelle kommunikation
> lohmühler berg 30 - 42553 velbert - fon 02053/504464 - fax 02053/923630
> <email address removed> - www.stoske-bertling.de - ftp.stoske-bertling.de
>
> - - - - - - - - - -
> For list commands, send "Help" in the body of a message to
> <<email address removed>>
>

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>