JNI ist langsamer als java.exe
-
Hallo,
ich komme gleich zum Punkt: Ich nutze den HSQL-Server 1.6.1 mit dem JRE 1.3.0. Um jetzt einen Windows-Dienst den Kunden zur Verfügung stellen zu können verwende ich jetzt die JNI-Schnittstelle 1.2 um den Zugriff auf die Java-Klassen zu ermöglichen. Soweit so gut, der Dienst läuft 1A.
In der Testumgebung fällt aber auf, dass die Ausführung des DB-Servers mit JNI um mehr als das 10fache langsamer ist als mit der java.exe
Ich weiß nicht, ob es an der Datentransferrate oder sonstigen Limitierungen liegt. Jedenfalls ist die Speicher- und CPU-Auslastung ca. gleich groß.Kennt sich dahingehend jemand aus? Ich meine, kann man JNI irgendwie optimieren um die selbe Leistung wie die java.exe rauszuholen?
Wenn ich mich konkreter ausdrücken soll einfach sagen
Bin schon am verzweifeln ...
-
Du verwendest also eine Java-Klasse mittels JNI und wunderst dich das es ohne JNI schneller geht?
Also ein Java Programm greift mittels JNI auf eine Java Klasse zu?btw, ist JNI-Schnittstelle nicht doppelt, JNI-Schnittstelle=Java Native Interface-Schnittstelle, auf Deutsch Java Native Schnittstelle-Schnittstelle
-
Jojo, deutsche Sprache schwere Sprache. Ne mal im ernst, hab's auf die Schnelle zusammengeschrieben und da achtet man nicht auf sowas
Nö, sry, es ist ein C++-Programm (ein Windows-Dienst) und greift auf Java-Klassen über JNI zu. Das Programm selbst ist bloß zur Steuerung des Datenbankservers gedacht - der Datenbankserver selbst ist komplett in Java geschrieben.
Hab gerade herausgefunden, dass es anscheinend an der jvm.dll des JDK 1.3.0 selbst liegt. Wenn ich denselben Code mit der jvm.dll und das JDK 1.4.2 ausführe ist es dann genauso schnell wie mit der java.exe des 1.3er (obwohl weiterhin die JNI-Version 1.2 verwendet wird).
Mensch, hoffentlich steigen wir bald auf 1.5 um...Falls aber trotzdem jemand ein paar Tipps hat immer her damit
-
Gibts einen zwingenden Grund wieso es ein in C++ geschriebenes Programm sein muss?
-
Weil es ein Windows-Dienst ist?
-
Korrekt, ein Windows-Dienst ist eine native Win32-Anwendung.
Hab's auch mal mit xyntservice versucht (ist eine Hilfsanwendung auf codeforge.com), aber selbst gemacht hält immer besser und macht mehr spaß ^^
-
Was kann ein Windows dienst, was eine javaanwendung nicht kann?
-
ein Service hat mehr rechte als ne normale anwendung....
-
Er läuft unter nem anderen User - ob das Ding in Java geschrieben ist oder nicht, tut dabei gar nichts zur Sache. Ich finde es seltsam, wie man da überhaupt einen Zusammenhang zur Programmiersprache sehen kann. Ja, es muss eine .exe in einem bestimmten Format sein. Sagt aber nichts darüber aus, ob die .exe nicht einfach ne VM starten kann.
-
shade37337 schrieb:
ein Service hat mehr rechte als ne normale anwendung....
Nein, nur andere. Ich kann z.B. mit einer Anwendng auf ein Netzlaufwerk zugreifen, wenn ich mich dort einlogge, aber der Dienst kann es deswegen noch nicht.
-
Ich bin jetz von den Windows standard einstellungen und ohne zusätzliche logins/passwörter ausgegangen.
wenn du z.B. nähmlich dem service beibringst genau wie der anwendung, sich wo einzuloggen, kann der das auch.Mfg
-
Optimizer schrieb:
Er läuft unter nem anderen User - ob das Ding in Java geschrieben ist oder nicht, tut dabei gar nichts zur Sache. Ich finde es seltsam, wie man da überhaupt einen Zusammenhang zur Programmiersprache sehen kann. Ja, es muss eine .exe in einem bestimmten Format sein. Sagt aber nichts darüber aus, ob die .exe nicht einfach ne VM starten kann.
Deswegen frag ich wieso es unbedingt eine in C++ geschriebenes Programm sein muss. Man kann doch auch die java.exe als Dienst eintragen, die dann eine Jar ausführt.
-
Das war als Antwort an TactX und Shadow gedacht. Ich teile deine Ansicht.
-
Oh, wusste nicht, dass man mit reinem Java (ohne Wrapper in C oder C++ oder sowas) einen vollständigen Windows Service (inkl. allem drum und dran: Kommunikation mit dem SCM, Eventlogs, ...) schreiben kann.
-
Davon war nicht die Rede, aber würde auch gehen. Wie das Compilat am Ende aussieht wird nicht durch die Sprachspezifikation bestimmt, sondern liegt allein im Ermessen des Compilerbauers. Und dann hängt es auch noch vom Betriebssystem ab, ob ein bestimmtes Compilat als Service taugt. Es gibt Betriebssysteme, die führen nur Java-Anwendungen aus.
-
Ich habe eine Dienst-Anwendung erstellt, weil Windows einen Einstiegspunkt für den Dienst braucht, und den kann man nur über native WinAPI Zugriffe registrieren.
Die java.exe an sich kann man nicht als Dienst eintragen. Man müsste dann ebenfalls eine Wrapper.exe schreiben, die sich als Dienst betätigt und die java.exe steuert. Darüberhinaus hat unsere Version des JRE keinen -Xrs-Parameter, was die JN-Schnittstelle jedoch unterstützt.
-Xrs = auf Systemsignale nicht achten, d. h. wenn Windows ein WM_QUIT sendet beendet sich die JVM nicht einfach so. Und da ein Dienst aber ohne Anmeldung am Server laufen können muss ist dieser Parameter für uns obligatorisch.Wie bereits erwähnt verwende ich jetzt für die Sonderfälle das JRE 1.4.2. Es ist "akzeptabel", solange lediglich der Server betrieben wird. Bei der JNI des 1.4.2 ist die Abarbeitungszeit genauso schnell wie mit der Ausführung der java.exe. Vielleicht gibt es bei 1.3.0 ein paar nicht ganz unerhebliche Leistungslücken, die man in der weiteren Entwicklung "gestopft" hat...