Created
September 8, 2011 03:46
-
-
Save nhocki/1202554 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# No es un poco más rápido sin el Date object? | |
# Crear un objeto cada vez es un poco feo. | |
# Sobre todo cuando es una función que se llama como 3mil veces | |
# Además, new Date(milisecs) es una mierda. | |
toHumanTime: -> | |
# date = new Date(@milliSeconds) | |
hours = Math.floor(@milliSeconds / (1000 * 60 * 60)) % 24 | |
mins = Math.floor(@milliSeconds / (1000 * 60)) % 60 # date.getMinutes() | |
secs = Math.floor(@milliSeconds / (1000)) % 60 # date.getSeconds() | |
hours = "0" + hours if hours < 10 | |
mins = "0" + mins if mins < 10 | |
secs = "0" + secs if secs < 10 | |
if hours < 1 | |
"#{mins}:#{secs}" | |
else | |
"#{hours}:#{mins}:#{secs}" |
De hecho, en JS la división no es entera? Pues, si es necesario ese Floor? O podríamos hacer parseInt(@mil / 1000, 10)
?
Por ahí hay una página para hacer benchmarks de JS. La voy a buscar y ahora hacemos uno.
Nada, no es entera, lo del benchmark sería brutal.
en JS:
>>> (1000000 / (1000 * 60 * 60)) % 24
0.2777777777777778
Yeah! Found it! http://jsperf.com/
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Esta fué mi aproximación inicial, también me parece bien, el único factor a considerar es el
floor
que hacemos ensecs
. Cuándo lo probé se veía raro (aveces rápido, aveces pegado el timer) pero en parte es debido al tiempo que le asignamos a los intervalos. Voy a jugar con los valores de nuevo. Yo creo esta función es más rápida.