Sorry, not O(n^2). It depends on the growth factor of the libc's std::string implementation which is often 1.5 and then it takes somewhere between O(n) and O(n^2) time. Growth factor of 2 would be O(n) but then it will also waste a lot of memory on average.

I guess my point is that std::string is not the best place to grow a string unless you know its size from the beginning.

URLFetcherCore::OnResponseStarted() could pass total_response_bytes_ to response_writer_ as a hint and URLFetcherStringWriter could call std::string::reserve().

I'd rather get things using it for more than a couple hundred K off of using in-memory buffers, and add a hard-limit for all consumers that can't be overridden.  The whole download stuff into memory until we crash thing just seems like a really bad API, particularly as some consumers use it for unencrypted HTTP requests.

See also issue 535601.

Hello. I would like to work/contribute to this ticket. Can the owner of this issue have me onboard on it?

claudiomdsjr:  Are you thinking of bratell's (entirely reasonable) solution to improve the status quo, or my significantly more involved pie-in-the-sky suggestion?  I'm assuming the former, though I suppose they aren't really exclusive of each other.

mmenke: I don't mind either implementations in particular. I would be more than glad to collaborate in both. I can see the trade off of both approaches to this issue, and as you recognised, the latter will require more careful planning, but I wouldn't mind being involved on that as well.

I do use //net a lot on many projects, so I'm familiar with its inner workings, however I've been using Chromium code for so long that I feel I should really be involved with it, rather than just consuming it for personal purposes... I'm just trying to get more involved with Chromium, and this ticket looked reasonably familiar to me.

I have no strong opinions here. I just stumbled upon this as a possible area of improvement while looking at out-of-memory issues and I'd welcome anyone improving it.

pauljensen's suggestion to preallocate the buffer seems like a good one, and restricting the API to "safe" usage also seems like a good one and neither excludes the other.

Agreed.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Archiving this - URLFetcher will no longer be used in Chrome in the foreseeable future.  Unclear if we'll be able to remove it entirely.