I'm planning to add a cache for the return value of method URL.Query.

1. Add two private fields of type URL

type URL struct {
	Scheme     string
	Opaque     string    // encoded opaque data
	User       *Userinfo // username and password information
	Host       string    // host or host:port
	Path       string    // path (relative paths may omit leading slash)
	RawPath    string    // encoded path hint (see EscapedPath method)
	ForceQuery bool      // append a query ('?') even if RawQuery is empty
	RawQuery   string    // encoded query values, without '?'
	Fragment   string    // fragment for references, without '#'

	lastRawQueryParsed string
	lastQueryResult Values
}

2. Use lastQueryResult as return value of method URL.Query when lastRawQueryParsed = RawQuery; otherwise get the return value first, then update the value of lastRawQueryParsed and lastQueryResult

Thanks for filing an issue and discussing a potential fix first.

The url.URL type is very low level and used by many Go programs. The benefit of this optimization will need to be evaluated against the cost very carefully.

It may not be viable to add unexported fields to the url.URL type, because it'll have significant effects on the usability of this type. For example, it won't be possible to compare two url.URL values with == operator reliably.

To have good performance, users can implement caching in their handlers if they need to use the result of Query method often:

q := req.URL.Query()
// ... use q many times

Alternatively, http.Request.FormValue already implements caching and can be used instead:

// use req.FormValue() many times

/cc @ianlancetaylor @dsnet

*I write the source code here instead of writing it in play.golang.org because on that environment the output was always elapsed time: 0s (no idea 🤷‍♂️️)

This is expected behavior. Computations are instantaneous on the Go playground and don't use up time. Read the Faking time section of the playground blog post.

Thanks for the advice @dmitshur.
I think the problem has been solved by http.Request.FormValue.

Is it OK to close this issue?

*TIL: http.Request.FormValue works for URL query. 😅

Glad to hear it!

Let's wait a few days to see if anyone else has more thoughts on this, but after that it should be fine to close.