
<html>Emberek és programozók! :-)<br /><br />Nem hagyott nyugodni a study-ban lévő runtime performance measurement eredménye, ezért újra mértem. A Boldi féle eredeti tesztmodell valóban nagyon rosszul skálázódik, de valószinűleg azért, mert korlát nélkül egy csomó objektumot hoz létre.<br />Ezért módositottam a modellt egy kicsit, hogy előre adott darabszámú objektumot tartson fenn folyamatosan. (Ha egy törlődik, egy másik létrejön helyette.)<br /><br />A másik gond az volt, hogy az eredeti txtUML-es mérés hibás volt, mert az egyik szálon végezte az időmérést, és hamarabb befejezte a mérést, mint hogy a modell ténylegesen terminált volna a másik szálon.<br /><br />További különbség, hogy nem guest eclipse-ben mértem, hanem mindent command line-ból, sima java-val.<br /><br />Az eredmények a csatolt fájlban. 100 objektum esetén a Model Executor kb. kétszer gyorsabb a txtUML-nél, de a txtUML sokkal jobban skálázódik sok objektum esetén, már 1000 objektum esetén is gyorsabb az Executornál és egy nagyságrenddel tovább is birja ebben a tekintetben.<br /><br />Üdv,<br />Gergő<br /> </html>