13 ms·
How many dates are you parsing at a time that optimizing this would make a noticeable difference to users?
by jnks 12y ago
How many dates are you parsing at a time that optimizing this would make a noticeable difference to users?
- evmar 12y agoThe post says: "For large object structures with thousands of date time objects this can easily add up." At 0.1ms per parse, that's 100ms per thousand dates, within the range of noticeable. (Their profiler screenshot has it taking 589ms.)
- imaginenore 12y ago0.1ms to parse a date??? Even the standard PHP string parser does 0.017ms on my 3 year old netbook. <?php $st = microtime(true); $cnt = 10000; for ($i=0; $i<$cnt; $i++) strtotime('2014-01-09T21:48:00.921000'); echo 1000 * (microtime(true) - $st) / $cnt; Seems like this solves a non-existing issue.
- anemitz 12y agoYou can see the issue it solves pretty clearly here: https://github.com/elasticsales/ciso8601#benchmark https://github.com/elasticsales/ciso8601#benchmark Python != PHP
- imaginenore 12y agoActually both Python and PHP are ridiculously slow languages. Though Python is slower.
- illumen 12y agoSome implementations of python are slowish for some tasks. Many parts, like the module being discussed are written in C/assembly/fortran/Java. Python with a jit is Pypy, http://speed.pypy.org/ http://speed.pypy.org/ Also PHP has some fast _implementations_ of PHP.
- grinich 12y agoLanguages aren't slow. Interpreters are. As a human, I can think a lot faster in Python. So for me, it's a faster language.
- philfreo 12y agoThis also doesn't do the same thing, since you're not constructing a DateTime object.
- easytiger 12y agoI do notice a lot of people on hackernews who clearly have never had to write high throughput software. Lots of people deal with data rates that make webscale throughput look pretty pathetic; you are just less likely to know as it will be prop tech