On Tue, Feb 18, 2020 at 8:57 AM Vincent Blanchon
wrote:
> Yes, definitely, good point.
> Both are them are good depending on the case actually.
>
>
> Le mardi 18 février 2020 16:55:02 UTC+4, Jan Mercl a écrit :
>>
>> On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon
>> wrote:
>>
>> > However, in
Yes, definitely, good point.
Both are them are good depending on the case actually.
Le mardi 18 février 2020 16:55:02 UTC+4, Jan Mercl a écrit :
>
> On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon
> > wrote:
>
> > However, in real code, I guess we will have that many constants, so it
> does
On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon
wrote:
> However, in real code, I guess we will have that many constants, so it does
> not make really sense to increase the number.
Design decisions may be driven by the desire to maximize the
performance in the average case or in the worst
With 100 constants:
Stringer-4 4.96ns ± 0%
StringerWithSwitch-4 4.99ns ± 1%
StringerWithMap-4 30.40ns ± 0%
The gap between the switch and the current implement is much smaller. I
guess it is due to the number of JMP instructions the code has to go
through.
It confirms that
On Tue, Feb 18, 2020 at 11:10 AM Vincent Blanchon
wrote:
> @Jan Thank you for the feedback. I will try with a higher number of
> constants. By the way, my benchmark tries all the path:
>
> func BenchmarkStringerWithSwitch(b *testing.B) {
>for i := 0; i < b.N ; i++ {
> p := Pill(i%20)
> I did not add it since it was not the original question ^^
> But why can't we have the check and a switch?
>
>
Definitely can. Just didnt see it. My response was somewhat tangential to
your question, sry.
--
You received this message because you are subscribed to the Google Groups
@Jan Thank you for the feedback. I will try with a higher number of
constants. By the way, my benchmark tries all the path:
func BenchmarkStringerWithSwitch(b *testing.B) {
for i := 0; i < b.N ; i++ {
p := Pill(i%20)
_ = p.String()
}
}
> I can't find any compile time check
On Tue, Feb 18, 2020 at 10:37 AM Vincent Blanchon
wrote:
> @Jan, yes definitely. By the way, here are some numbers from a benchmark I
> made with 20 constants:
>
> name time/op
> Stringer-4 4.16ns ± 2%
>
> StringerWithSwitch-4 3.81ns ± 1%
>
> StringerWithMap-4
@Brian, this code is generated by the stringer command based on this
code: https://play.golang.org/p/JNfRC5TZYlo
@Jan, yes definitely. By the way, here are some numbers from a benchmark I
made with 20 constants:
name time/op
Stringer-4 4.16ns ± 2%
On Tuesday, 18 February 2020 09:04:49 UTC, Jan Mercl wrote:
>
> > A simpler and faster way again would be to use a map.
> > https://play.golang.org/p/ntjhesMsSA9
>
> I don't see how could be map lookup possibly faster than slice
> indexing. Have you some measurements to share?
>
>
No, I didn't
The const/slice implementation should be faster as Jan said.
Note that there is also a blank function that fails at compile time if
items have been added or changed and stringer has not been rerun since.
The const/slice implementation allows for that (useful!) check.
Le mardi 18 février 2020
On Tue, Feb 18, 2020 at 9:47 AM Brian Candler wrote:
>
> Could you provide a link to where you found this code? I imagine it was done
> that way just for demonstrating some features of go, such as slicing and
> array lookups.
>
> A simpler and faster way again would be to use a map.
>
Or, indeed, an array of strings.
https://play.golang.org/p/3Eg9va4Krqo
--
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+unsubscr...@googlegroups.com.
Could you provide a link to where you found this code? I imagine it was
done that way just for demonstrating some features of go, such as slicing
and array lookups.
A simpler and faster way again would be to use a map.
https://play.golang.org/p/ntjhesMsSA9
--
You received this message
14 matches
Mail list logo
