Make MediaType.toString faster

[GoogleCodeExporter]

Recently I got a pull request removing direct usage of MediaType.toString in 
favor of storing its output in constants.  We were using MediaType.toString to 
render "Content-Type" header values for HTTP responses.  Apparently it was slow 
enough that it took up 13% of the total CPU time to handle the responses.

https://github.com/TechEmpower/FrameworkBenchmarks/pull/386#issuecomment-2135052
1

(I mention in a comment there that I wasn't able to observe the performance 
impact.  That is because I was looking at HTTP requests per second and my 
testing environment was network-limited.)

That's a shame - I wanted to use MediaType specifically to avoid creating my 
own constants.  Can MediaType just be faster?  I want to have my cake and eat 
it very quickly.

In my use case, I render the same MediaType instances as strings many times, so 
memoizing the result gives the biggest boost.  Adding ".precomputed()" to 
MediaType.TOKEN_MATCHER also gives a slight boost (for non-memoized results).

Original issue reported on code.google.com by michael.hixson@gmail.com on 23 Jul 2013 at 3:40

[GoogleCodeExporter]

Original comment by kak@google.com on 23 Jul 2013 at 4:10

• Added labels: Package-Net, Type-Performance

[GoogleCodeExporter]

I love this sort of bug report.  Our general feeling on MediaType.toString() 
was "we could make this faster, but let's wait until somebody actually cares."  
Well, this counts. :-)

I think we can do a few things that'll help:
1) precompute stings for the constants.  seems like an easy win.
2) use single-check lazy init (since the operation is idempotent) for the 
toString() value
3) take a look at StringBuilder sizing.  We're probably doing extra copies that 
make it unnecessarily expensive.

Original comment by gak@google.com on 23 Jul 2013 at 6:03

[GoogleCodeExporter]

Original comment by gak@google.com on 23 Jul 2013 at 6:03

• Changed state: Accepted

[GoogleCodeExporter]

For what it's worth, I tested a few ways to optimize toString on the first run 
(i.e. when its result is not cached).  They're nothing in comparison to what 
could be gained from gak's suggestions (1) or (2), of course.

I attached the results it spit out.  Basically the first run of toString could 
be 2-3x faster.

Original comment by michael.hixson@gmail.com on 25 Jul 2013 at 12:31

Attachments:

• benchmark.txt

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit