On 19 October 2012 21:13, Strake wrote:
> On 19/10/2012, Calvin Morrison wrote:
>> I think the largest benefit is the cache. Loading up many
>> http://google.com's would mean you'd have to reload all of the images
>> and such, whereas with one process, you wouldn't have an opportunity
>> of overl
On 19/10/2012, Calvin Morrison wrote:
> I think the largest benefit is the cache. Loading up many
> http://google.com's would mean you'd have to reload all of the images
> and such, whereas with one process, you wouldn't have an opportunity
> of overlap cache.
So make a local HTTP caching proxy.
On 19 October 2012 13:16, Carlos Pita wrote:
>> I have mixed feelings about this idea.
>>
>> On the one hand, I like that new windows are new processes. It makes
>> sense, and ensures that unix tools like kill, and I imagine workload
>> schedulers, work as expected.
>
> I know. I just think that t
> I have mixed feelings about this idea.
>
> On the one hand, I like that new windows are new processes. It makes
> sense, and ensures that unix tools like kill, and I imagine workload
> schedulers, work as expected.
I know. I just think that the memory tradeoff is significant enough to
pay this c
Quoth Carlos Pita:
> I've coded this patch that considerably reduces surf memory usage
> (and some LOCs) by avoiding the creation of a new process each
> time a new webview is created.
I have mixed feelings about this idea.
On the one hand, I like that new windows are new processes. It makes
s
Hi all,
I've coded this patch that considerably reduces surf memory usage (and
some LOCs) by avoiding the creation of a new process each time a new
webview is created. The patch is very simple, it just replaces calls
to newwindow with calls to a slightly modified newclient. This only
applies to "i
