Gabriele Svelto wrote:
Another common case of OOMs are people building inside a VM. Just
yesterday I helped another mozillian figure out why his FxOS build had
started to fail. It turned out he was building inside a VM with too
many jobs and too little memory dedicated to it.
I often build
On 28/11/2013 10:57, Neil wrote:
I often build in a VM. I allocate 2 CPUs and 2GB of RAM to it, which
seems to be enough even to link xul.dll with debug symbols, although it
takes a few minutes. (Linking it without symbols takes just seconds.)
Given the amount of memory needed to link I haven't c
As many of you know, Session Restore is something of a performance hog,
for many reasons – we have reports of. One of the reasons is that we
store so very many things in sessionstore.js and sometimes keep stuff
for a very long time.
As part of bug 943352 & followup, we are considering automaticall
On Thu, Nov 28, 2013 at 11:56 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> As many of you know, Session Restore is something of a performance hog,
> for many reasons – we have reports of. One of the reasons is that we
> store so very many things in sessionstore.js and sometimes kee
On Mon, Nov 25, 2013 at 6:59 PM, Lawrence Mandel wrote:
>> If not, is there a better way to do this than duplicating probes and
>> checking the pref to see which probe should be fed?
>
> A probe is not restricted to boolean values. You can define a histogram that
> maps values to conditions. As s
On 11/28/13 1:33 PM, Till Schneidereit wrote:
> This would all be tackled after we did other things like getting rid
> of all history entries for iframes, which won't be restored in any
> case, right?
We're not sure about the relative priorities of this cleanup vs.
removing the history entries for
On Thu, Nov 28, 2013 at 1:55 PM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> On 11/28/13 1:33 PM, Till Schneidereit wrote:
> > This would all be tackled after we did other things like getting rid
> > of all history entries for iframes, which won't be restored in any
> > case, right?
>
On 11/28/2013 12:56 PM, David Rajchenbach-Teller wrote:
As many of you know, Session Restore is something of a performance hog,
for many reasons – we have reports of. One of the reasons is that we
store so very many things in sessionstore.js and sometimes keep stuff
for a very long time.
As part
On 11/28/2013, 2:29 AM, Gabriele Svelto wrote:
On 28/11/2013 08:09, Gregory Szorc wrote:
Peak RSS likely has increased significantly (hundreds to gigabytes
range).
OK, that's what I was curious about.
Memory is cheap and getting cheaper. Nobody paid by Mozilla to develop
Firefox should have
On 11/28/2013, 12:14 PM, Ehsan Akhgari wrote:
Please file a bug (and CC me) with more details about where the build
fails, how much memory the machine has, and how much memory each
compiler invocation consumes (test with make -j1). We can adjust the
number of files we build in one chunk per d
On 11/25/2013, 7:41 PM, Gregory Szorc wrote:
The repo was hiding that old changeset because it has been obsoleted
(Mercurial changeset evolution magic). I updated the server config to
expose hidden changesets, so the link works again.
However, the changeset has been obsoleted, so you'll want to
On 11/28/2013, 1:21 PM, Mike Hoye wrote:
On 11/28/2013, 12:14 PM, Ehsan Akhgari wrote:
Please file a bug (and CC me) with more details about where the build
fails, how much memory the machine has, and how much memory each
compiler invocation consumes (test with make -j1). We can adjust the
num
On Thu, Nov 28, 2013 at 1:12 PM, Ehsan Akhgari wrote:
>
> Right. FWIW, this is probably as good a forum as any to voice my objection
> on the recent trend of recommending people to buy new hardware to get faster
> builds. There is a *lot* that we can still do in order to improve our build
> time
On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
I'm pretty sure that gps was saying "if you're paid to work by
Mozilla, get a faster machine". More generally, we're all in furious
agreement: fast builds are good; achieving them via multiple means is
worthwhile; those with the option of getti
On 11/28/2013, 4:55 PM, Mike Hoye wrote:
On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
I'm pretty sure that gps was saying "if you're paid to work by
Mozilla, get a faster machine". More generally, we're all in furious
agreement: fast builds are good; achieving them via multiple means is
wo
Can we guarantee UTF16 literals using MOZ_UTF16("wide string here")
these days? I'm just reviewing a patch and it's using the old-style
NS_LITERAL_STRING("wide string here").get() pattern all over.
--
Warning: May contain traces of nuts.
___
dev-platf
On Thu, Nov 28, 2013 at 05:12:53PM -0500, Ehsan Akhgari wrote:
> On 11/28/2013, 4:55 PM, Mike Hoye wrote:
> >On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
> >>I'm pretty sure that gps was saying "if you're paid to work by
> >>Mozilla, get a faster machine". More generally, we're all in furious
On 11/28/13, 7:15 AM, Honza Bambas wrote:
On 11/28/2013 12:56 PM, David Rajchenbach-Teller wrote:
As many of you know, Session Restore is something of a performance hog,
for many reasons – we have reports of. One of the reasons is that we
store so very many things in sessionstore.js and sometime
On 11/29/13 12:15 AM, Matthew N. wrote:
> On 11/28/13, 7:15 AM, Honza Bambas wrote:
>> On 11/28/2013 12:56 PM, David Rajchenbach-Teller wrote:
>>> As many of you know, Session Restore is something of a performance hog,
>>> for many reasons – we have reports of. One of the reasons is that we
>>> sto
- Original Message -
> From: "Bas Schouten"
> To: dev-platform@lists.mozilla.org
> Cc: "David Major" , "Nathan Froyd" ,
> "Firefox Dev"
> Sent: Tuesday, November 26, 2013 1:15:44 AM
> Subject: Re: Reacting more strongly to low-memory situations in Firefox 25
>
>
> - Original Messa
On Thu, Nov 28, 2013 at 10:26:43PM +, Neil wrote:
> Can we guarantee UTF16 literals using MOZ_UTF16("wide string here")
> these days? I'm just reviewing a patch and it's using the old-style
> NS_LITERAL_STRING("wide string here").get() pattern all over.
There's only one definition of NS_LITERA
David Rajchenbach-Teller schrieb:
As part of bug 943352 & followup, we are considering automatically
cleanup some of the contents of sessionstore.js.
Just for my understanding (I have commented to users with huge, e.g.
~100MB sessionstore.js in bugs as well), I thought we were working on a
re
22 matches
Mail list logo
