Closed sjudd closed 10 years ago
Interesting idea. We see this a lot in Picasso for allocations.
I submitted a more aggressive and allocation-optimized version of this to https://github.com/square/okhttp/pull/961.
I can cherry pick those changes here if you don't mind? Thanks for taking a look and pointing it out.
This project has diverged a bit from the reference implementation inside of OkHttp. This week is crazy with Google I/O, can you give me a week or so and I'll see what we can pull up into this project for a new release?
I'm totally fine to wait a week, thanks for being willing to do that. Let me know if I can help!
This is out of date and includes a bunch of other commits on my fork, closing. Happy to re-open with the correct commit or help with forking at some point.
While trying to reduce garbage collections in a sample app, I noticed that this library allocates a couple of strings per request (once for the file name, and once to join the directory and the file name) which generates enough garbage to cause gcs to noticeably increase in frequency.
The largest strings I saw were around 300 characters so the memory overhead of holding on to the files for each entry is probably pretty small. Even with 5000 entries in memory at once the total overhead would be less than 3mb (300 characters * 2 bytes per character * 5000 entries). At the same time even with only a few items per row, scrolling a list could easily generate a couple of kB worth of garbage per row.