| 著作一覧 |
90年代のごく最初か80年代の終わり頃か、気持ち良くtime(2)とか(今ならgettimeofdayになるのかな)呼びまくってたら、「遅くなるからやめろゴラ」と怒られたものだが。
というわけで多分、何も考えてないのだと思うがやたらめたらとSystem.currentTimeMillisだのCalendar.getInstanceだのを呼んでいるプログラムを見ると気になる。
トレースとかだってstartとstopをトレース側に用意しておけば有効無効に連動して時刻呼び出しの有無を切り替えられるはずなのに、地のほうで差を求めてトレースに与えたりしてるのを見かけるし。
import java.util.Calendar;
import java.util.GregorianCalendar;
public class Day {
static Calendar createByCalendar(int y, int m, int d) {
Calendar c = Calendar.getInstance();
c.clear();
c.set(Calendar.YEAR, y);
c.set(Calendar.MONTH, m - 1);
c.set(Calendar.DAY_OF_MONTH, d);
return c; // getInstanceで常にクロック読み取りするってのが変だと思う。new Dateもそうだが。
}
static Calendar createByGregorianCalendar(int y, int m, int d) {
return new GregorianCalendar(y, m - 1, d);
}
public static void main(String[] args) {
for (int i = 0; i < 3; i++) {
long l = System.currentTimeMillis();
for (int j = 0; j < 10000; j++) {
Calendar cal = createByCalendar(2005, 1, 1);
}
System.out.println("経過:" + (System.currentTimeMillis() - l));
l = System.currentTimeMillis();
for (int j = 0; j < 10000; j++) {
Calendar cal = createByGregorianCalendar(2005, 1, 1);
}
System.out.println("経過:" + (System.currentTimeMillis() - l));
}
}
}
で、多分、200ナノ秒くらいかと予想してやってみる。
C:\test>java Day 経過:296 経過:47 経過:78 経過:31 経過:78 経過:47
1GHz P-III、Windows2000だと3〜4マイクロ秒もかかるのか。ちなみにSparc Solarisのやっちいやつで試したら想像どおり200ナノ秒ちょっとというところだった。
でも、この数の裏側にいろいろなやり取りがあるわけだし。OSとハードの実装に依存するのだが、システムクロックの読み取りというのは余り気軽にやって欲しいものではない。というか、ユーザーがやらなくても、JVMをtrussするとすさまじくクロック読み取りしているように見えるのだが。
ジェズイットを見習え |