Lehet ezen még gyorsítani?

Java

https://github.com/haa-zee/proc_speedtest/blob/master/Proc_Speed_Test.j…

A feladvány annyi volt, hogy a /proc/[0-9]*/stat fájlokból kiolvasson egyetlen sort minél gyorsabban, 10000 alkalommal.
A pythonos változata kb. 40s alatt futott, ennek az eredetije, tutorialokból összeollózva 55-65s, a jelenlegi, némi doksi olvasás után kb. 35s.
Az optimalizálás annyiból állt, hogy amit lehetett cikluson kívülre tettem és a "new BufferedReader( new FileReader(...) )" helyére "Files.newBufferedReader(...)" került.
Lehet ezen még gyorsítani?

  • 1279 megtekintés

( dotnetlinux | 2018. 03. 31., szo – 09:31 )

Algoritmikusan rendben, a kodban már sokminden nem áthelyezheto. 4.5ms/iteracio elég jó eredmény, már csak a csúnya kernel ne irogatna a fájlokat.

Gyorsba csekkeltem alternativ modon, szvsz ez itt mar a kernelen mulik.
@snail:~/tbs/lua/proc_stat_speed_test$ time ./luajit test.lua
4108285 0

real 0m42.784s
user 0m13.936s
sys 0m28.348s

A luajit sajat patch-el optimalizalt, lfs szintugy, a szuboptimalis lua kod meg ez volt:
@snail:~/tbs/lua/proc_stat_speed_test$ cat test.lua

require 'lfs'

sDir = '/proc'

ctr, err = 0, 0

for i = 0, 10000, 1 do

for sFileName in lfs.dir( sDir ) do
if string.match( sFileName, '^[0-9]*$' ) then
local fStatFile = io.open( sDir ..'/'.. sFileName ..'/stat', 'r' )
if fStatFile then
local sLine = fStatFile:read()
if sLine then
ctr = ctr +1
else
err = err +1
end
fStatFile:close()
end
end
end

end

print( ctr, err )

szerk.: nem baratsagos a tabulalas, szori.

Köszi, de továbbra sem értem, a kernel hol befolyásolja a dolgokat.

A teszt onnan ered egyébként, hogy kíváncsi voltam, egy saját monitoring program, ami többek közt a processzeket figyeli, mennyire terhelné a gépet különböző nyelveken. Szóval a lényeg csak annyi, hogy azonos gépen milyen eltérések vannak a különböző megvalósítások között.

1 file-tartalom felovasasa legalabb 3 fs kernelhivas. A feladat 3/4-e a kernelben zajlik. Talan vmi kernelhook-os trukkel lehetne meg faragni, de az meg rendszerszinten "fekez".

Igazabol elegedett vagyok az egyszalas sebessegevel, azert nem rossz 4 millio fajl open-read-close 40sec alatt. :D

Köszi!
Azért ettől a luajit-től padlót fogtam rendesen... :)
Főleg azt követően, hogy állítólag a java JIT közel natív sebességet produkál a marketing szerint.
(mondjuk az eddigiek szerint nem kizárt, hogy valóban, csak a különböző package-ek használata annyit lassít rajta, hogy nem igazán látszik)

Ha erdekel kozelebbrol is, nagyon javaslom a kozelrol megtekinteset. Nagyon okos mind a lua, mind a jit megvalositasa. Nem is ertem, hogy pl. a python/ruby sloware hogy birt eletben maradni mellette. :DDD (Ha asol picit, akkor a tarantool meg fasza cucc.)

A jvm meg nagyon sok mindent tesz melle, szoval piszkosul nem egy ligaban buliznak azert.

Go/Rust implementaciot nem tervezel..?

Basszus... hibás állapotot küldtem fel a githubra :(((
Szerintem így "gyorsabb", csak nem csinál semmit ;)
Hülyébb vagyok, mint hittem. Nem csak a repoba került hibásan, így is teszteltem :(
Érdekes, hogy a directory-t(??) simán beolvasta, hibaüzenet nélkül. :)
Így valóban gyorsabb, nyertem vele még 3 mp-et...
Köszi.

Githubon is javítva.

Ez meg gyorsabb:


for(Path path : stream){
Path path2file = path.resolve("stat");

try ( Stream br = Files.lines(path2file))
{
String line;
line = br.findFirst().get();
ctr++;
} catch(IOException e){
err++;
}
}

a stream persze string generic parammal van, csak kiszedi a drupaaal
----------------------
while (!sleep) sheep++;