strconv: add equivalents of Parsexxx() with []byte arguments

[remyoudompheng]

Hello,

Just like we have FormatFloat(...) string and AppendFloat(...) []byte, it would be nice
to avoid a costly string conversion when parsing numbers from a byteslice.

Simple code like:

func main() {
  s := "123.45"
  r := bytes.NewBufferString(s)
  runtime.UpdateMemStats()
  println(runtime.MemStats.Mallocs)
  var v float64
  fmt.Fscanf(r, "%f", &v)
  runtime.UpdateMemStats()
  println(runtime.MemStats.Mallocs)
}

says it's doing 7 allocations in the Scanf.

[adg]

Comment 1:

Sounds like a nice idea.
Naming suggestions? "ParseFloatBytes"?

Labels changed: added priority-later, removed priority-triage.

Status changed to HelpWanted.

[rsc]

Comment 2:

I would like to think more about this.
It doubles everything, and we may be able to avoid
it with careful compilation.

[bradfitz]

Comment 3:

Regarding "careful compilation", see my comment in the duplicate issue #3197.

[bradfitz]

Comment 4:

Issue #3197 has been merged into this issue.

[bradfitz]

Comment 5:

From issue #3197:
I attempted to convert strconv's Parse internals to use []byte instead, and then make
the existing string versions make an unsafe []byte of the string's memory using
reflect.SliceHeader / reflect.StringHeader, but the reflect package already depends on
strconv, so there's an import loop.

[remyoudompheng]

Comment 6:

In the meanwhile, when I had to parse many numbers and save some allocations, I would
convert a big []byte to a big string and slice from it, instead of slicing from the
[]byte and string-ifying each chunk.

[bradfitz]

Comment 7:

I wonder if reflect.SliceHeader / StringHeader should be mirrored in package runtime.

[bradfitz]

Comment 8:

Implemented here, for discussion at some point:
http://golang.org/cl/5759057/
The byte view approach may be considered either gross or lovely. Not sure. The grossness
is isolated, well tested, and can't escape to callers at least.

[rsc]

Comment 9:

I am much less worried about the implementation than the expansion of the API.

[bradfitz]

Comment 10:

True but this API was already extended with Append* for []byte efficiency, and this just
mirrors that.
And we already have nearly-duplicate strings and bytes packages.  This []byte/string
duplicity is unfortunate, but this is far from the only place.
Still, Later.

[rsc]

Comment 11:

Like I said in #2, we may be able to do better with Parse
than with Format/Append.  The distinction is that Parse
accepts strings as input, while Format returns strings as
output.  It is easier to analyze the former than the latter.

[bradfitz]

Comment 12:

Yeah, there's a whole bunch of string<->[]byte optimizations that would be nice.
issue #2204 comes to mind.  And in another project, I want to be able to do a lookup in a
map[string]T with a []byte key. It'd be nice if:
      var m map[string]T = ...
      var key []byte = ...
      v, ok := m[string(key)]
...  didn't generate garabage too.

[remyoudompheng]

Comment 13:

I think we have an issue about "escape analysis of strings" already. If a string([]byte)
does not escape, it won't be stored so further modifications to the []byte are safe even
if the string was created zero-copishly. Ah it's issue #2205, but it's about
[]byte(string).
The string([]byte) case does not require read-only flagging, I think, only ordinary
escape analysis.

[bradfitz]

Comment 14:

Labels changed: added performance.

[bradfitz]

Comment 15:

Labels changed: added garbage.