time.Format vs. fmt.Sprintf

[Benjamin Polidore]

Looks like time.format is a little slow relative to making a simple Sprintf.

These two funcs:

func RenderTime(t time.Time) string {

  return t.Format("20060102-15:04:05.000")

}

vs. 

func RenderTimeManual(t time.Time) string {

  return fmt.Sprintf("%d%02d%02d-%02d:%02d:%02d.%03d",

    t.Year(),

    t.Month(),

    t.Day(),

    t.Hour(),

    t.Minute(),

    t.Second(),

    t.Nanosecond()/100000)

}

Have the following performance:

BenchmarkRenderTime           500000      3811 ns/op

BenchmarkRenderTimeManual  500000      2558 ns/op

This makes sense to me because time.Format has to parse the format string first and then essentially do what I'm doing with my Sprintf.  It would probably be good to allow users to "compile" the time.Format once and then reuse it since this is something that people probably run in a tight loop for logging, etc. 

bp

[Kyle Lemons]

It's worse than that, actually :).  For heavy logging, formatting a time more than once per second is a major time sink.  In my log4go package, I maintain a CoW time cache based on a logging format that considerably reduces the average format time of the date portion of a log message.

That being said, I think the standard library functions are well suited for common use cases, and that users who find them a bottleneck can probably still leverage the library to write more performant code without having to rewrite it.  Since the particular bottleneck will differ from application to application, I don't think it should be up to the standard library to do it.  For instance, log4go logs sequentially, and as such its bottleneck is in re-formatting the same date repeatedly.  Some other applications might be rendering many non-sequential times (for instance, doing directory listings) and need to find another strategy for improving throughput.

[Gustavo Niemeyer]

On Wed, Apr 4, 2012 at 23:42, Benjamin Polidore <poli...@gmail.com> wrote:
> This makes sense to me because time.Format has to parse the format string
> first and then essentially do what I'm doing with my Sprintf.  It would
> probably be good to allow users to "compile" the time.Format once and then
> reuse it since this is something that people probably run in a tight loop
> for logging, etc.

Haven't you essentially just solved the problem in a single statement? :-)

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.

[Brad Fitzpatrick]

The problem is even worse than you point out.

From the time you call time.Now() until the time gets printed, three microseconds have elapsed and your output is no longer correct.  Be sure to compensate for that.

On Wed, Apr 4, 2012 at 7:42 PM, Benjamin Polidore <poli...@gmail.com> wrote:

[Russ Cox]

On Wed, Apr 4, 2012 at 22:42, Benjamin Polidore <poli...@gmail.com> wrote:
> It would probably be good to allow users to "compile" the time.Format once
> and then reuse it since this is something that people probably run in a
> tight loop for logging, etc.

Maybe you should look into why you are logging in a tight loop.

Russ

[Benjamin Polidore]

I'm dealing with a protocol that requires a full timestamp with milliseconds in the format i've described on each message.  I'll probably optimize a little further beyond my Sprintf example, but I wanted to share this observation.

[Benjamin Polidore]

Thanks, very helpful response.  I might try a modified version of your cache.  Thinking I can detect how stale is the timestamp and update only part of it since my format has increasing time precision from left to right.

[chrisho...@gmail.com]

Sometimes projects have upstream requirements that you can't change, avoid, or redefine. Sometimes you don't have a choice in how or what data you're providing downstream to other consumers. 

[Robert Engels]

I will add that high performance logging is a requirement of most financial applications - although usually it is a binary format that is "pretty formatted" later for archival/searching, sometimes on demand.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0d2b4402-7e24-421f-a5de-31775b472ae0%40googlegroups.com.

[Dan Kortschak]

This thread is 7 years old.

[Robert Engels]

Funny. Did you remember it or just pay close attention to these things?

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fa535c9348925f7d5fbc01c924e2569abd967eb9.camel%40kortschak.io.

[Dan Kortschak]

I couldn't find the thread in my go-nuts box, so I looked for it on
google groups.

Chris, it may be relevant, but the thread is stale and so the
conversation is unlikely to be productive, particularly if people don't
have the previous comments that led up to this reanimation.

[Leo R]

Dan is the only one in this thread who pays attention to the actual value of the timestamp not just to its format :-)

--Leo

On Tuesday, July 23, 2019 at 7:45:37 PM UTC-4, Robert Engels wrote:

Funny. Did you remember it or just pay close attention to these things?

> On Jul 23, 2019, at 6:38 PM, Dan Kortschak <d...@kortschak.io> wrote:
>
> This thread is 7 years old.
>
>> On Tue, 2019-07-23 at 12:03 -0700, chrisho...@gmail.com wrote:
>> Sometimes projects have upstream requirements that you can't change,
>> avoid,
>> or redefine. Sometimes you don't have a choice in how or what data
>> you're
>> providing downstream to other consumers.
>>
>>
>>> On Thursday, April 5, 2012 at 3:24:09 PM UTC-4, Russ Cox wrote:
>>>
>>> Maybe you should look into why you are logging in a tight loop.
>>>
>>> Russ
>>>
>>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Wojciech S. Czarnecki]

On Tue, 23 Jul 2019 18:45:14 -0500
Robert Engels <ren...@ix.netcom.com> wrote:

> Funny. Did you remember it or just pay close attention to these things?

I personally did not remember nor I paid close attention, I just read it.

> >>> On Thursday, April 5, 2012 at 3:24:09 PM UTC-4, Russ Cox wrote:

> >>> April 5, 2012
(for ascii impaired webpages)

April 5, 2012
(for insane mail clients that cut all interleaved citations)

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Chris Hornberger]

Well, I got here on topic #2 on a google search for golang date sprintf, soooooo. Relevant, topical, easily found.

[Dan Kortschak]

I'm offering advice about how to more effectively use the group. Feel
free to ignore it.