Różnica między System.currentTimeMillis() a datem getTime()?

Question

Miałem nadzieję, że uda się wycisnąć niewielki wzrost wydajności z wielu wywołań funkcji, która zwraca znacznik czasu. Funkcja wygląda tak:

public static long get_now_ms(){ 
    // returns number of MILLISECONDS since epoch 
    java.util.Date d = new java.util.Date(); 
    return d.getTime(); 
} 

mogę po prostu zastąpić ten z:

public static long get_now_ms(){ 
    // returns number of MILLISECONDS since epoch 
    return System.currentTimeMillis(); 
} 

znam tej daty wewnętrznie używa System.currentTimeMillis(). Moje pytanie brzmi raczej, czy czas letni lub strefa czasu letniego może kiedykolwiek doprowadzić do różnicy w wyniku tych dwóch podejść. Wyobrażam sobie, że może to pochodzić z obiektów kalendarza, ale nie obiektów Date, ale chciałbym trochę wyjaśnienia na ten temat.

Wiem, że prawdopodobnie nie zobaczę zauważalnej różnicy w wydajności w aplikacjach świata rzeczywistego, ale mimo to chciałbym znać odpowiedź.

Dzięki!

Answer 1

Bez różnicy, z wyjątkiem bardzo niewielkiego opóźnienia spowodowanego przez przydzielenie obiektu Date.

Z javadoc The domyślny konstruktor Date:

alokuje obiekt Date i inicjuje go tak, że reprezentuje czas, w którym został przydzielony, mierzony z dokładnością do milisekundy.

A Date to tylko cienkie opakowanie w milisekundach epoki, bez żadnej koncepcji stref czasowych. Tylko w przypadku renderowania do String jest brana pod uwagę strefa czasowa, ale jest to obsługiwane przez klasę Locale.

Answer 2

Sugerowałbym wykonanie testu jednostkowego (np. https://gist.github.com/ledlogic/8532028). Widziałem tylko niewielką ogólną korzyść z działania System.currentTimeMillis w stosunku do (new Date()). GetTime().

1 billion runs: (1000 outer loops, 1,000,000 inner loops): 
    System.currentTimeMillis(): 14.353 seconds 
    (new Date()).getTime(): 16.668 seconds 

Poszczególne przebiegi czasami są nieco stronnicze w stosunku do późniejszego podejścia - w zależności od aktywności systemu.

Answer 3

Bez różnicy, a Calendar.getTimeInMillis() również jest takie samo. ponieważ wynikiem powrotu jest liczba milisekund od 1 stycznia 1970 roku, 00:00:00 czasu GMT. dostaniesz tę samą długą wartość, gdziekolwiek jesteś na całym świecie.