On 2013 Sep 09, at 13:14, Marcel Weiher wrote:
On 2013 Sep 9, at 18:11 , Jens Alfke wrote:
[...]
[fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took
26.97 µsec
[fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook
0.47 µsec (58x)
Now, the tradeoff is that the o
> I’m not sure if you meant that ironically, but it’s absolutely not premature.
> I’ve run into major NSDateFormatter bottlenecks — as in “hm, over half the
> time to open this file is spent inside NSDateFormatter” — at least twice, and
> the author of the blog post I linked to says that he also
On Sep 9, 2013, at 11:46 , Tom Davie wrote:
> On 9 Sep 2013, at 20:29, Rick Mann wrote:
>
>>
>> On Sep 9, 2013, at 09:25 , Maxthon Chan wrote:
>>
>>> This may not be that useful in all circumstances - I always send dates as
>>> milliseconds since the UNIX epoch as 64-bit signed integers. T
On 9 Sep 2013, at 20:29, Rick Mann wrote:
>
> On Sep 9, 2013, at 09:25 , Maxthon Chan wrote:
>
>> This may not be that useful in all circumstances - I always send dates as
>> milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way*
>> faster to parse.
>
> Yes. It's ridi
Just to add a tiny wrinkle:
On Sep 9, 2013, at 20:27 , Jens Alfke wrote:
> On Sep 9, 2013, at 10:48 AM, Jeffrey Oleander wrote:
>> [..] Some do, but the dread of customer rebellion is strong, and they want
>> to enter them in the slap-dash, hurried, harried ways they're used to
>> writing them
On Sep 9, 2013, at 09:25 , Maxthon Chan wrote:
> This may not be that useful in all circumstances - I always send dates as
> milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way*
> faster to parse.
Yes. It's ridiculous that a lot of JSON APIs send ISO 8601-formatted (or
On Sep 9, 2013, at 10:48 AM, Jeffrey Oleander wrote:
> The issue is users entering dates […] am sorely wishing I could just enforce
> ISO date entry as in the quoted example by using pop-up menus. Some do, but
> the dread of customer rebellion is strong, and they want to enter them in the
>
On Sep 9, 2013, at 11:35 AM, Jens Alfke wrote:
> I’m not sure if you meant that ironically, but it’s absolutely not premature.
> I’ve run into major NSDateFormatter bottlenecks — as in “hm, over half the
> time to open this file is spent inside NSDateFormatter” — at least twice, and
> the auth
On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
> Premature optimization is the root of all evil!
I’m not sure if you meant that ironically, but it’s absolutely not premature.
I’ve run into major NSDateFormatter bottlenecks — as in “hm, over half the time
to open this file is spent inside N
On Sep 9, 2013, at 19:35 , Jens Alfke wrote:
>
> On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
>
>> Premature optimization is the root of all evil!
>
> I’m not sure if you meant that ironically, but it’s absolutely not premature.
Absolutely! On both counts. It just seems to be the app
What's premature about it?
-- Tito
> On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
>
> Hi Jens,
>
> Premature optimization is the root of all evil!
>
> Er, I misspelled: “very cool, nice job!”
>
>> On Sep 9, 2013, at 18:11 , Jens Alfke wrote:
>>
>> [..]
>> [fg160,160,160;16:34:40.48
On Sep 9, 2013, at 19:20 , Tito Ciuro wrote:
>> On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
>> Premature optimization is the root of all evil!
> What's premature about it?
Nothing:
>> Er, I misspelled: “very cool, nice job!”
:-)
Marcel
_
On Sep 9, 2013, at 19:05 , Jean-Daniel Dupas wrote:
>
> Le 9 sept. 2013 à 18:11, Jens Alfke a écrit :
>
>> [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97
>> µsec
>> [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47
>> µsec (58x)
>
> Isn't
Hi Jens,
Premature optimization is the root of all evil!
Er, I misspelled: “very cool, nice job!”
On Sep 9, 2013, at 18:11 , Jens Alfke wrote:
> [..]
> [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec
> [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDate
Le 9 sept. 2013 à 18:11, Jens Alfke a écrit :
> Parsing dates from strings can be surprisingly expensive — more than once
> I’ve seen it show up as the primary hot-spot in code that reads files or
> parses network data. NSDateFormatter is very flexible, but you pay for that
> in speed. If you
This may not be that useful in all circumstances - I always send dates as
milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way*
faster to parse.
On Sep 10, 2013, at 0:11, Jens Alfke wrote:
> Parsing dates from strings can be surprisingly expensive — more than once
> I’ve
16 matches
Mail list logo
