A super, java embedded, na tu jsem uplne zapomnel, very good point!!!
No ja jsem si udelal nejaka srovnani ohledne volani napr nejakeho unix commandu, jeho reimplementace v jave volanim jak z on demand JVM, tak nacachovane JVM s temito vysledky:
Soubor 280MB
Java implementace pouziti unix4j:
/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package testingunixutilsjava;
import java.io.File;
import org.unix4j.Unix4j;
/**
*
* @author zANGETSu
*/
public class TestingUnixUtilsJava {
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
Unix4j.cat("/home/zangetsu/test.txt").grep("TecMint.com").sort().toStdOut();
}
}
Linux util
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#time cat test.txt | grep "TecMint.com" | sort
real 0m11.798s
user 0m0.128s
sys 0m1.084s
Standard JVM
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#time java -jar TestingUnixUtilsJava/dist/TestingUnixUtilsJava.jar
real 0m18.507s
user 0m8.161s
sys 0m0.208s
Drip
root@acheron:/media/sf_Dev/rep/trunk/wat/TestingUnixUtilsJava/dist#/root/bin/drip -cp TestingUnixUtilsJava.jar testingunixutilsjava.TestingUnixUtilsJava
real 0m18.395s
user 0m0.016s
sys 0m0.044s
Jak vidno, tak to spise vypada, ze bude problem ve vlastni implementaci utilit. Jednoduse javova implementace cat, grep a sort dohromady v tomto pripade v jave neni tak vykonna jako original, coz jsem cekal. No zmensim proto soubor na nula cela nula nic, takze uvidim vysledek vlastniho startu:
Linux util
real 0m0.051s
user 0m0.000s
sys 0m0.004s
opakovane:
real 0m0.003s
user 0m0.000s
sys 0m0.000s
Standard JVM:
real 0m0.371s
user 0m0.244s
sys 0m0.088s
opakovane:
real 0m0.382s
user 0m0.272s
sys 0m0.072s
Drip
Zde provedu test na bezici procesy, jelikoz se drip pri prvnich testech urcite demonizoval:
ps -ef |grep drip
root 9031 1 0 18:42 pts/1 00:00:00 /root/drip/bin/drip_daemon /usr/bin/java -Djava.awt.headless=true -classpath /root/drip/bin/../drip.jar:TestingUnixUtilsJava.jar org.flatland.drip.Main testingunixutilsjava.TestingUnixUtilsJava /root/.drip/0.2.3/ebd029dbc177dca5f783f1de6842f7d8edfadfa4/9011-1
root 9034 9031 0 18:42 ? 00:00:00 /usr/bin/java -Djava.awt.headless=true -classpath /root/drip/bin/../drip.jar:TestingUnixUtilsJava.jar org.flatland.drip.Main testingunixutilsjava.TestingUnixUtilsJava /root/.drip/0.2.3/ebd029dbc177dca5f783f1de6842f7d8edfadfa4/9011-1
root 9175 3732 0 18:45 pts/1 00:00:00 grep drip
# kill -n 9 9031 9034
Nyni predpokladam, ze start pres drip bude dokonce mozna o trochu horsi nez standardni JVM, jelikoz je tam nejaky svinstvo okolo, musi se vytvorit znovu deamon apod. Uvidim:
real 0m0.475s
user 0m0.260s
sys 0m0.080s
a opakovane:
real 0m0.463s
user 0m0.008ssys 0m0.008sreal 0m0.470s
user 0m0.004ssys 0m0.012sNo je videt, ze exekuce na urovni kernelu i mimo-kernel trvala opravdu velmi male casove okamziky. Co uz tu neni videt a proto cislo real zustava stale vysoke, je exekuce na urovni jineho procesu, kde je rozjeta JVM z minuleho runu. Rekl bych, ze jsem nezvolil nejlepsi priklad. Umim si predstavit, ze zde k vyraznemu narustu vykonu dojde az napr. pokud pouzivame velky set classpath. Takhle se to rozhodne nevyplati.
Jinak exekuce probihala na virtualnim debianu.
Zobrazit příspěvky
