Summary: | Page with a form, five multi-line fields, large strings, Webkit RSIZE grows and grows | ||
---|---|---|---|
Product: | WebKit | Reporter: | Rainer Joswig <joswig> |
Component: | Forms | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | Normal | CC: | ap, beidson, darin, mitz, mrowe |
Priority: | P2 | Keywords: | InRadar, NeedsReduction |
Version: | 528+ (Nightly build) | ||
Hardware: | Mac (Intel) | ||
OS: | OS X 10.6 |
Description
Rainer Joswig
2009-10-13 05:07:13 PDT
(In reply to comment #0) > Hi, > > I am using Webkit, a nightly build. The process listing systems says 'Safari' > (does it then really use Safari?). Safari is the application. WebKit is the framework used by the application to render web content. > As an debugging example I have written a page with form which has five > multi-line fields and a submit button. The fields have a default content of > random strings of about 2 million characters each. So the page size is roughly > five * 2 million characters. This is also the size on disk, if I save the form > from the browser. The form page is dynamically generated by the server (no > static text file). Transfer is HTTP 1.1. Can you share the example page so that we can reproduce the scenario that you’re testing with? That should make it quite easy for us to reproduce the results and investigate the memory growth. Thanks for the bug report! See this page: http://www.cl-http.org:8002/large-form It's a server running on a small Mac mini, so don't expect any performance wonders and I wrote a very stripped down page. The form page contains a submit button and five fields. For each field I list the number of characters on top. The string is static in this example and all fields have the same string content. The response page has a link back to the form and then prints the number of return fields and for each field the length of received data. Let me know if you have questions about the example. I should mention that submitting the form really posts the ten MB data, so with a slow upstream connection it might take some time. With my ADSL line a post takes a minute or two. Are you able to share the source of the dynamic page so that I could set up the same server locally to bypass the network overhead and ensure that we can test this even if your machine is not available? the server machine is a separate Mac mini running all the time and should be available, it is itself not behind ADSL. If you have a fast network access (which Apple sure has ;-) ) , the performance should be no problem at your side. The server and the page generation code is written in Lisp (it is a PPC application currently), so not that helpful if only Apache/etc. knowhow is available. If you really really really really want to run it locally, I could make that PPC application available. I assume the format data is all sitting in the back/forward list so we can resubmit the form. Do other browsers perform better? form data, not format data Oh, I see, 10MB times 10 is not 1GB. I suspect what we are seeing here is simply due to multiple copies of the large rendering tree that are kept around due to back/forward caching. If we tried the same experiment closing the window each time I suspect we would not see the memory growth. |