Ne, ze bych chtel neco menit na tom, co jsem uz napsal, ale konecne jsem
se poradne podival *jak* to nio pouzivate, a zjistil jsem, ze jsem byl
off topic. Na tohle to nio proste musi byt rychlejsi. Asi je to
to, co tu psal nedavno napriklad pan Buchta: nechte kazdeho zavodnika
kopirovat maly soubor desettisickrat na stejne misto (aby se nezacaly
projevovat lookupy v prodluzujicim se adresari). Cas merte jenom v tom
souctu. Dostanete (predpokladam) opacny vysledek. Dejte vedet.
A jeste proc Vam jednou vyslo 1 ms a jednou 12 ms? Muj tip je, ze behem
druheho mereni se naschedulovalo neco jineho. 10ms je priblizna perioda
linuxoveho timeru. Ale to berte jenom jako priklad, proc nelze merit
realny (vnejsi) cas a pritom ho nechat uplynout malo. I kdybyste ten
pokus opakoval mockrat, muze byt nejaky systematicky duvod, proc to muze
10x vyjit stejne zkreslene.
Omlouvam se za nepozornost v prvnim mailu.
Jirka
On Wed, Aug 31, 2005 at 11:15:47PM +0200, Jirka Hanika wrote:
> On Mon, Aug 29, 2005 at 11:33:27AM +0200, Martin Kuba wrote:
> > [EMAIL PROTECTED] wrote:
> > > V tomto konkretnim pripade navic jeste je dobre pouzit NIO kvuli vykonu
> > >(je to obrovsky rozdil), ale hlavni je funkcnost.
> >
> > Zkusil jsem si ted porovnat klasicke IO a NIO a vychazi mi, ze NIO
> > je pomalejsi:
> >
> > import java.io.*;
> > import java.nio.channels.*;
> >
> > public class Copy {
> > static final int BUFSIZE = 1024*64;
> > public static void main(String args[]) throws IOException {
> > if(args.length!=2) {
> > System.err.println("Usage: java Copy <src_file> <dst_file>");
> > System.exit(1);
> > }
> > long t1 = System.currentTimeMillis();
> > classicIO(args[0],args[1]+".old");
> > long t2 = System.currentTimeMillis();
> > newIO(args[0],args[1]+".new");
> > long t3 = System.currentTimeMillis();
> > System.out.println("size: "+(new File(args[0]).length())+"
> > CLASSIC: "+(t2-t1)+"ms NIO: "+(t3-t2)+"ms");
> > }
> >
> > static void classicIO(String src,String dst) throws IOException {
> > BufferedInputStream in = new BufferedInputStream(new
> > FileInputStream(src),BUFSIZE);
> > BufferedOutputStream out = new BufferedOutputStream(new
> > FileOutputStream(dst),BUFSIZE);
> > byte[] buffer = new byte[BUFSIZE];
> > int nacteno;
> > while((nacteno=in.read(buffer,0,BUFSIZE))>0) {
> > out.write(buffer,0,nacteno);
> > }
> > in.close();
> > out.close();
> > }
> > static void newIO(String src,String dst) throws IOException {
> > FileChannel in = new FileInputStream(src).getChannel();
> > FileChannel out = new FileOutputStream(dst).getChannel();
> > out.transferFrom(in,0,in.size());
> > in.close();
> > out.close();
> > }
> > }
> >
> > Kdyz spustim:
> >
> > size: 4589 CLASSIC: 1ms NIO: 12ms
> > size: 37400824 CLASSIC: 135ms NIO: 121ms
> >
> > tj. pro dlouhe soubory se to srovnava, ale pro male je klasicke IO
> > rychlejsi. Jak to ?
>
> Popularni nio je proste vice low-level pristup. Takze prechod
> na nio ma smysl
>
> 1) pokud se topite ve stovkach threadu, na nez zakonite vede naivni
> implementace masove vyuzivaneho serveru (napr. web serveru), a to
> predevsim, pokud vetsina tech threadu se jen nudi cekajic, zda se laxnim
> uzivatelum nezlibi poslat pozadavek
>
> 2) pokud vite presne, co chcete delat jinak nez io, napriklad
> v zajmu rychlosti. Napriklad Vam vadi nekolikanasobne kopirovani dat po
> pameti
> a alokace vselijakych pomocnych objektu tam, kde byste treba mohl pametove
> namapovat binarni soubor, zorientovat se v nem pomoci primitivnich typu,
> zmenit v nem par bajtu a hotovo.
>
> V ten moment je nio dar z nebes. Jinak je to zbytecne zneprehledneni a
> zpomaleni kodu, protoze napr. poll() je pochopitelne pomalejsi, nez synchronni
> read() na jediny kanal - a to jeste Suny podezrivam, ze mozna kvuli
> prenosnosti pouzivaji vzdy select(), kterezto API s bitovymi poli pevne delky
> lze omluvit pouze jeho stareckymi sedinami a rozsirenosti.
>
> Tvrzeni, ze "nio je rychlejsi nez io", je povera sirena proto, abychom se
> vsichni naucili nio pouzivat a nadale si mohli vybirat z io a nio dle
> momentalni potreby :-)
>
> Jirka
