Makrovergleich

[ErnstVolker]

Hallo zusammen,

ich beschäftige mich momentan damit eine Textdatei auszulesen. Das funktioniert auch Dank der Hilfe aus diesem Forum.

Ziel ist es, Teile der Datei in LibreOffice/OpenOffice Tabellenkalkulation einzulesen. Das habe ich mittlwerweile auch geschafft. Direkt aus Lazarus heraus in die Zellen von Calc, Zugriff via OLE hergestellt.

Zum Vergleich der Performance wurde das auch mit OO-VBA vorgenommen, und hier ist festzustellen, dass das FPC/Lazarus-Makro schneller arbeitet.

Jetzt würde mich interessieren ob jemand von Euch ähnliche Test's mit seinen Makros durchgeführt hat. Auch im Vergleich zu Python- und/oder Java.

Ist auf jeden Fall zu erwarten, dass FPC/Lazarus Makros schneller sind?

Hat von Euch mal jemand versucht C++ Makros für OpenOffice/LibreOffice zu schreiben? Das erscheint mir doch recht aufwendig wenn man sich die Beispiele so ansieht. Wobei hier sicherlich auch der Weg über OLE gegangen werden kann.

Gruß

Volker

[Socke]

Ist auf jeden Fall zu erwarten, dass FPC/Lazarus Makros schneller sind

Das kommt darauf an, wie OOo/LibreOffice VBA umgesetzt hat. Wenn VBA interpretiert wird, ist FPC auf jeden Fall schneller, da hier alles direkt vom Prozessor ausgeführt werden kann. Ansonsten kommt es noch ein wenig darauf an, welche Variablentypen in VBA verwendet werden; Variant ist immer ineffizienter als ein richtig verwendeter long usw.

[Hitman]

Mit Java, C++ und soweit ich weiß auch Python kannst du OOo direkt per UNO steuern. Das ist auf jeden Fall nochmal schneller, wenn du es richtig machst ... und funktioniert auch unter Linux und Mac OS. Theoretisch gibt es sogar eine Pascal-UNO-Bridge, die ist aber mit FPC etwas "spannend" zu bedienen.

Die höchste Performance kriegst du aber nur mit C++ hin. Nur damit hast du _alle_ Funktionalitäten der UNO Schnittstelle und es müssen keine Datentypen übersetzt werden. Bei der Java UNO Schnittstelle sieht das schon düsterer aus; bei Python sicherlich ähnlich. Gerade wenn du Number-Crunching mit Calc betreiben willst, dürfte der Unterschied erheblich sein.

[ErnstVolker]

Die Pascal uno bridge hatte ich mir mal runtergeladen und grob hineingesehen. Das sind die letzten Veröffentlichungen 2007 gewesen. Da scheint sich nicht mehr viel zu tun.

Ich dachte VBA und Python würden interpretiert und wären somit grundsätzlich langsamer als ein vom Prozessor ausgeführtes Programm.
Ich habe aber so ein "Gefühl", dass ggf. ein Python-Makro doch schneller ist als ein's in Lazarus/FPC -trotz Interpreter.

UNO wird auch unter Pascal verwendet. Man holt sich halt via Late Binding mit CreateOleObject("com.sun.star.ServiceManager"); den Zugriff und dann geht's los...
Bei VBA und Python gibt es halt aus uno den: CreateUnoService("com.sun.star.ServiceManager").

Ich bin noch nicht dazu gekommen meinen Textdurchsucher auf Python umzustellen. Es scheint ein wenig bucklig zu sein Python-Makros an den Start zu bekommen. Einige funzen nur über Extras->Makros->Ausführen...
usw., Andere können einer Schaltfläche zugewiesen werden. Da muss dann eine xml-Datei angepasst werden. Das sind so Dinge die mich eher Abschrecken. Dieses elende Gefummel an noch weiteren Stellen...

Python wäre insofern interessant in Verbindung mit Calc zu benutzen, dass man es schafft entweder diverse Zusatzpakete wie Numpy, scipy, matplotlib in's Office-Python zu installieren, oder umgekehrt das "System-Python" mit seinen "Zusätzen" zum Ausführen der Office-Makros nutzten. Das Letztere scheint irgendwie zu gehen, sofern man in den Umgebungsvariablen einige Pfade umstellt.

Ich habe momentan mein XP frisch aufgesetzt und mir den OpenWatcom C++ Compiler installiert (für den Fall mal was mit C++ probieren zu wollen). Ich hatte keine Lust auf MS 2010/2008 Express Edition. Da installiert sich immer so viel Drösel aus .Net und Zeugs mit, den ich noch weniger brauche als C++ ...
Aber es wird (zumindest unter Windows) empfohlen den MS-Compiler zu verwenden wenn man C++ Makros oder auch AddInns für's OpenOffice/LibreOffice proggen will.

Ich dachte es hätten sich hier im Forum ggf. Einige nebenher (außerhalb Lazarus oder im Vergleich dazu) mal mit Makros für OpenOffice beschäftigt...

Gruß

Volker

[Hitman]

Ich dachte es hätten sich hier im Forum ggf. Einige nebenher (außerhalb Lazarus oder im Vergleich dazu) mal mit Makros für OpenOffice beschäftigt...

Nicht falsch gedacht ... NLPSolver ("Solver for Nonlinear Programming") und PalOOCa sind auf meinem Mist gewachsen. Beides Extensions für OOo Calc und in Java geschrieben.

Ein bisschen muss man hier wohl noch in der Terminologie aufpassen, damit wir auch nicht aneinander vorbei reden. Macros sind eigentlich eher OOo-interne Scripte. Dafür steht StarBasic (sowas VBA mäßiges), JavaScript und soweit ich weiß Python zur Verfügung.
Dann gibt es die Remote Interfaces (wobei man das sicher mit als "Macro" sehen kann), worüber man sich von außen eine Instanz von OOo organisiert (einen UNO Service) und diesen dann steuert. Das kann direkt über UNO erfolgen (Bindings für Java, Python und natürlich C und C++ liegen OOo bei), oder halt über einen Adapter (OLE, .NET/CLI, ...).

Dann gibt es da noch die Extensions, die meines Wissens nur UNO nutzen dürfen/können und direkt im Kontext von OOo ausgeführt werden. Sie erzeugen also keine eigene Instanz des OOo UNO Services, sondern kriegen die bestehende mitgeliefert.

Die UNO Bridges sind der direkteste Zugriff, den man von außen haben kann, was von sich aus also schonmal einen Geschwindigkeitsvorteil bringt. Je nach Sprache, müssen aber Datentypen dennoch übersetzt werden. Tauscht man also viele Daten aus (was gerade bei Calc häufig der Fall ist: nimm Wert A, schreib ihn in eine Zelle, berechne Wert B, gib diesen zurück), müssen viele Datentyp-Transformationen durchgeführt werden. Bei Java kommt man da schon nicht drum herum, da allein die Strings nicht dem entsprechen, was OOo-intern genutzt wird. (Wenn mich nicht alles täuscht nimmt Java UTF-16 und UNO UTF-8).
Da OOo selbst in C++ geschrieben ist, kann über die UNO-C++-Bridge quasi direkt kommuniziert werden; ohne Mapping. So führst du den Code fast so aus, als wäre er Teil von OOo. Das einzige, was dich so oder so verlangsamen wird ist, dass viele der öffentlichen/finalen UNO Schnittstellen Locking benutzen. Allerdings hast du mit der C++ Bridge an vielen Stellen die Möglichkeit, sowas zu umgehen und ggf. sogar inoffizielle Schnittstellen zu nutzen. Allein was User Interfaces angeht hast du teilweise gar keine Wahl; nicht unerhebliche Teile der VCL sind nur von C++ aus nutzbar. (Achtung: nicht zu Verwechseln mit Borland's VCL, die hier in Lazarus-Kreisen ja auch gern mal erwähnt wird )

Was Performance angeht, wirst du denke ich in etwa so aufgestellt sein:
C/C++ > Java > Python > COM/OLE > StarBasic

Wo genau sich dort die Pascal-UNO-Bridge einordnet, kann ich nur vermuten: zwischen C/C++ und Java.

Man muss es natürlich immer im Kosten/Nutzen-Verhältnis sehen. Wenn der Datenaustausch mit OOo das Kleinste ist, also die meiste Rechenarbeit innerhalb von OOo oder dem eigenen Programm stattfindet, kann man das alles sicherlich vernachlässigen. Dann tut auch COM/OLE nicht weh.

[ErnstVolker]

Hallo Hitman,

danke für die umfangreiche Antwort.

Ich habe jetzt mal meim Python-Skript fertiggestellt und ausprobiert. Es scheint augenscheinlich geringfügig schneller zu sein als die Lazarusvariante. Aber nur unwesentlich. Eine Stoppuhr habe ich nicht integriert. Reines Beobachten.
Bei Starbasic kann man mit dem Mausrad vorscrollen und mit zugucken wie die Strings in die Zellen geschrieben werden. Also da sind Lazarus und Python deutlich schneller.
Die Pascal-uno-Bridge habe ich noch nicht probiert.

Deine Java-Extensions scheinen ja recht umfangreich zu sein und einen nicht unerheblichen Anteil an GUI-Funktionalität aufzuweisen. Ich hatte mal SimForge (eine GUI-Anwendung) am Start, und war von der Lahmheit überrascht. Ich dachte schon mein Rechner sei kaputt. Dann bin ich beim Stöbern im Freebasic-Forum auf ein Thema gestoßen da ging es allgemein um Programmiersprachen und ein Beitrag war, dass Java bei größeren GUI-Anwendungen eher lahm sei. Das wundert mich, wo doch so viel von Java die Rede ist. Liegt es am Rechner, an der Art der Programmierung einer JAVA-Anwendung dass diese langsam ist?

So, jetzt werd' ich mich mal für ein paar Tage verabschieden. Morgen geht's in eine Herzklinik, Vorhofflimmerablation machen lassen und hoffen dass es hilft.

Gruß

Volker

[Socke]

Das wundert mich, wo doch so viel von Java die Rede ist. Liegt es am Rechner, an der Art der Programmierung einer JAVA-Anwendung dass diese langsam ist?

Java ist immer noch langsamer als native Programme aus Pascal oder C/C++, da hier ein Bytecode von einer Virtuellen Maschine ausgeführt wird (also so etwas wie ein Prozessor emuliert wird).
Da moderne Computer aber immer leistungsfähiger werden, kann man diese Langsamkeit immer weniger wahrnehmen. Daneben gibt es noch andere Techniken (Just in Time Compilierung; Hot-Spot-Optimierung), die eine Java-Software beschleunigen können.

Selbstverständlich kann man auch beim Programmieren viel falsch machen, aber das ist kein Problem von Java (sondern des Programmierers).

[Hitman]

Das wundert mich, wo doch so viel von Java die Rede ist. Liegt es am Rechner, an der Art der Programmierung einer JAVA-Anwendung dass diese langsam ist?

Java ist immer noch langsamer als native Programme aus Pascal oder C/C++, da hier ein Bytecode von einer Virtuellen Maschine ausgeführt wird (also so etwas wie ein Prozessor emuliert wird).
Da moderne Computer aber immer leistungsfähiger werden, kann man diese Langsamkeit immer weniger wahrnehmen. Daneben gibt es noch andere Techniken (Just in Time Compilierung; Hot-Spot-Optimierung), die eine Java-Software beschleunigen können.

Selbstverständlich kann man auch beim Programmieren viel falsch machen, aber das ist kein Problem von Java (sondern des Programmierers).

Offtopic: Die gängigen JVMs nutzen JIT-Compilation. Daher läuft ein Algorithmus in der Regel sehr performant (wenn er nicht total dämlich programmiert wurde natürlich ), das Laden neuer Klassen dauert aber eben etwas, weil dann der JIT-Compiler erstmal kurz zu tun hat. .NET z.B. nutzt AOT (also Ahead-Of-Time) Compilation, übersetzt also prinzipiell erstmal _alles_ nach Maschinencode. Hat auch was für sich, aber führt (ohne Caching) zu höheren Initialen Ladezeiten ... die stören aber ja sowieso nicht.

Ich habe jetzt mal meim Python-Skript fertiggestellt und ausprobiert. Es scheint augenscheinlich geringfügig schneller zu sein als die Lazarusvariante. Aber nur unwesentlich. Eine Stoppuhr habe ich nicht integriert. Reines Beobachten.
Bei Starbasic kann man mit dem Mausrad vorscrollen und mit zugucken wie die Strings in die Zellen geschrieben werden. Also da sind Lazarus und Python deutlich schneller.

Schau dir in dem Zusammenhang mal die (UNO) Funktionen lockControllers und unlockControllers (vom XModel Interface) an. Das deaktiviert eine Reihe von Events, wodurch das Ausfüllen der Zellen erheblich schneller geht. In der Regel sieht das (in StarBasic) so aus:

Code: Alles auswählen

ThisComponent.LockControllers
'Zellen füllen ...........
'.......
'.....
ThisComponent.UnlockControllers
ThisComponent.CalculateAll 'Alles neu Berechnen lassen; wurde vorher ja nicht gemacht, da Events aus waren

Das Sollte man natürlich vorzugsweise auch von Python, Pascal, Java, etc. aus machen. Das Prinzip bleibt ja das gleiche.

So, jetzt werd' ich mich mal für ein paar Tage verabschieden. Morgen geht's in eine Herzklinik, Vorhofflimmerablation machen lassen und hoffen dass es hilft.

Ohje, ich drück die Daumen. Gute Besserung (bzw. viel Erfolg)!