[*]Profan

Sebastian
König

Mag vielleicht ganz praktisch sein, aber dass es mehr Geschwindigkeit bringen würde, bezweifle ich. Bei solchen Container-Aufrufen muss ja immer ein Stringvergleich zur Laufzeit durchgeführt werden (i.e. Schleife!)... damit sich dieser Overhead lohnt, müssten die Farbfunktionen schon ausreichend aufwendig sein.

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

14.03.2009 ▲

Drum mag ich das Prinzip auch nicht sonderlich.

Da rgb bereits eine Funktion ist, vielleicht rgb.mix().

14.03.2009 ▲

Wie relevant würdest Du den Overhead einschätzen bei z.B. einer Funktion mit konstant 2 Long-Parametern?
Kompilieren Markieren Separieren

proc rgb.test(l1&,l2&)

    return rgb(getRValue(l1&),getGValue(l1&),getBValue(l1&))+rgb(getRValue(l2&),getGValue(l2&),getBValue(l2&))

endproc

Sebastian
König

Hmm, ist schwer einzuschätzen...

Für eine Umsetzung in einer Containerfunktion spricht natürlich, dass damit die Berechnung an sich nativ ausgeführt wird. Dagegen halt die Sache mit dem Stringvergleich. Genauer gesagt: Wenn man nicht der erste ein TRUE ergibt, sind es sogar mehrere, denn eine solche Containerfunktion sieht ja immer etwa so aus: (natürlich in PASCAL

)
Kompilieren Markieren Separieren

if (cmd$ = Befehl)

    ...

elseif (cmd$ = AndererBefehl)

    ...
    usw.

endif

Ob man also einen Geschwindigkeitsvorteil hat, hängt also wohl nicht nur von der Komplexität der Funktion, sondern womöglich auch noch von der Stelle in der Abfrage-Liste ab...

Für Profan2Cpp zumindest wäre die Container-Variante ziemlich sicher langsamer. Vielleicht hat meine Bewertung zu sehr einen Bias in diese Richtung...

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

Könnte man vielleicht, wenn der Parameter eine Stringkonstante ist und kein Argument, den Aufruf vorher in einen statischen Aufruf konvertieren. (Lieber einmalig diese Last des Stringvergleiches als zur Laufzeit.)

Sebastian
König

Ja, zur Optimierung von API-Aufrufen gehe ich zum Teil schon in diese Richtung...

Nachtrag: Bei XProfan selbst mag das vielleicht nicht mit dem Grund, warum die Container-Funktionen ursprünglich eingeführt wurden, vereinbar sein. Ging es nicht irgendwie um eine Knappheit von Funktionsnummern?

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

Ich wollts nur nicht ansprechen.

Roland könnte doch
Kompilieren Markieren Separieren

rgb.lauterNamen(farbe1&,farbe2&)

mit seinem Präkompiler umwandeln in eine Kontainer-Funktion
Kompilieren Markieren Separieren

interneKontainerFunktion(eineKonstante oder rgb.lauterNamen,farbe1&,farbe2&)

[offtopic]XPSE tut so z.B. bei alten Create-Funktionen.[/offtopic]

17.03.2009 ▲

Sebastian
König

Ich wollts nur nicht ansprechen.

(...) mit seinem Präkompiler umwandeln in eine Kontainer-Funktion
Kompilieren Markieren Separieren

interneKontainerFunktion(eineKonstante oder rgb.lauterNamen,farbe1&,farbe2&)

In dem Fall, in dem dort wieder ein String steht, hätte man ja nichts gewonnen... Die Variante mit eineKonstante macht da schon eher Sinn - aber dann könnte man auch gleich ein paar interne Header-Definitionen dafür einbauen und sich die Umwandlung mit dem Präkompiler sparen...

[offtopic]
Ich mag irgendwie die Schreibweise mit dem Punkt nicht so... zwar gibt es offiziell (leider!) keine Liste von Zeichen, die in XProfan-Namen (für Funktionen, Prozeduren, Variablen etc.) vorkommen dürfen, aber mit Blick darauf, dass der Punkt im Moment schon zum Zugriff auf Attribute und Methoden benutzt wird, bewegt man sich mit seiner freien Verwendung zumindest in einer Grauzone...
[/offtopic]

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

17.03.2009 ▲

Kompilieren Markieren Separieren

In dem Fall, in dem dort wieder ein String steht, hätte man ja nichts gewonnen...

Der Trick beseitigt das ID-Mangel-Problem, dass könnte schon ein Gewinn sein.

Auch ein String ist imho garnicht notwendig - gibt doch genug IDs im Format Long:

eineFunktionsName(5,6,7)

umwandeln vom in XProfan eingebauten Präkompiler in
Kompilieren Markieren Separieren

interneKontainerFunktion(66,5,6,7)

Danach kann Roland imho neue Funktionsnamen erfinden ohne auf die IDs achten zu müssen.

17.03.2009 ▲

Weil ich auf lange Sicht weder damit "leben" würde wollen, dass ein Overhead solche Funktionen verlangsamt, noch das solche Funktionen zu realisieren möglicherweise so langwierig wäre, musste eine Lösung her.

Also habe ich mir Deine MemoryModule.Inc [...]

geschnappt um mir Inline-Assembler bereitzustellen.

Letztendlich sind ziemlich nette nProcs [...]

(alpha) dabei herausgekommen, mal schauen ob mir dies den gewünschten Effekt bereitet - wenn der Tag doch nur 200h hätt. ^^

26.10.2009 ▲