Firefox 28 Release Notes • Hacker News Board

Re: Firefox 28 Release Notes

#161

Post by fulafel » Wed, Mar 19, 2014, 2:48 PM UTC

ris wrote: post #159

mrinterweb wrote: post #145

Earlier quoted context omitted.

I suppose I was mislead by the mozilla wiki link I posted which states at the top "The goal of the project is to run web content in a separate process from Firefox itself. The two major advantages of this model are security and performance. Security would improve because the content processes could be sandboxed"

The effect is overstated & overrepeated, especially with facilities like e.g. ptrace being available to processes on linux

No, ptrace() is not available to Chrome's sandboxed processes. Not in the SUID sandbox and not in the BPF seccomp sandbox.

This stuff is described at http://code.google.com/p/chromium/wiki/LinuxSandboxing - if after reading that you still don't think it provides a significant additional layer of security, it would be interesting to hear what flaws you see.

Re: Firefox 28 Release Notes

#162

Post by gsnedders » Wed, Mar 19, 2014, 4:25 PM UTC

mraleph wrote: post #160

gsnedders wrote: post #130

Earlier quoted context omitted.

Octane is the continuation of V8 benchmark (and contains all of the V8 benchmark tests) — V8 (the JS engine) was specifically designed to provide good performance on those tests (this is why V8 had a generational GC from launch, for example; though somewhat amusing last I checked Carakan (Opera/Presto's last JS engine) was quickest at splay, primarily a GC benchmark, despite having a very naïve GC!). The tests new in…

hint: Splay is a benchmark that penalizes generational GCs. If you have a fast mark-sweep GC with an aggressive growth policy you are going to totally rock it.

I may slightly be showing how long it's been since I looked at Splay. :)

My memory was that originally V8 was out-performing everyone else primarily because the initial allocation (into the nursery) was way quicker than anyone else did. Or maybe it was freeing the nodes that die young?

Certainly I remember both SpiderMonkey and Carakan spending huge amounts of time on GC on Splay, and Carakan's massive speed-up came when the object representation was changed (GC actually asymptotically regressed as a result, but in almost every practical case cache-locality (and reduction of memory accesses) outweighed it).

Re: Firefox 28 Release Notes

#163

Post by rch » Thu, Mar 20, 2014, 3:42 AM UTC

marcosdumay wrote: post #93

rch wrote: post #35

Earlier quoted context omitted.

You could handle this with configuration, as others have. Edit: judging from the other comments, maybe you have already.

No, you can not. If you don't have a separated search bar, your only options are enabling or disabling autocomplete. There is no option of using autocomplete just when you want it. Also, the local autocomplete of the address bar is great. Count me as another one that does not want to miss it.

I was letting him slide with exactly that: an on/off switch. But with additional configuration one could use a 'g ' prefix to activate autocomplete via Google, for instance.

Re: Firefox 28 Release Notes

#164

Post by nnethercote » Sat, Mar 22, 2014, 12:48 PM UTC

nnethercote wrote: post #88

twoodfin wrote: post #13

Earlier quoted context omitted.

Any idea why the "slim" numbers are moving steadily in the wrong direction?

Partly it's just that the browser is getting more features. Things like WebRTC are a ton of code. More generally, AWSY is useful for identifying some regressions, but it's one specific, unrealistic workload. You can't use it to judge Firefox's overall memory consumption. For example, looking at AWSY you'd think Firefox 13 had the best memory consumption. But I guarantee you that Firefox 28 has better memory consumpti…

Nonetheless, the increase isn't good. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=986323 about this, and have started investigating.