On 7/13/18 5:22 PM, gsquel...@mozilla.com wrote:
E.g., could I instrument one class, so that every allocation would be tracked
automatically, and I'd get nice stats at the end?
You mean apart from just having a memory reporter for it?
Including wasted space because of larger allocation
On Wednesday, July 11, 2018 at 4:19:15 AM UTC+10, Kris Maglione wrote:
> [...]
> Essentially what this means, though, is that if we identify an area of
> overhead that's 50KB[3] or larger that can be eliminated, it *has* to be
> eliminated. There just aren't that many large chunks to remove.
> On Jul 13, 2018, at 3:05 PM, Frank-Rainer Grahl wrote:
>
> > This is just one piece of the broader XUL removal effort, but it does
> > highlight that things can be simpler in a post-XUL world.
>
> Well I agree that cleaning up overlay usage was overdue. Otherwise the simple
> post XUL
> This is just one piece of the broader XUL removal effort, but it does
> highlight that things can be simpler in a post-XUL world.
Well I agree that cleaning up overlay usage was overdue. Otherwise the simple
post XUL world world is just dumb. Removing things without a functional
replacement
On Fri, Jul 13, 2018 at 02:10:54PM -0700, Brendan Dahl wrote:
This is hopefully the last thing you’ll ever hear about XUL overlays as
they have now been completely removed from Firefox[1].
\o/ Thank you to everyone who was involved in this!
Removing overlays cut around 3.5K lines of code
This is hopefully the last thing you’ll ever hear about XUL overlays as
they have now been completely removed from Firefox[1]. For those unfamiliar
with overlays, they provided a way to merge two XUL documents and were
mainly used by legacy extensions and in several places within the Firefox
UI.
tl;dr: A major change to the architecture preference service has just landed,
so please be on the lookout for regressions.
We've been working for the last few weeks on rearchitecting the preference
service to work better in our current and future multi-process configurations,
and those
On Fri, Jul 13, 2018 at 11:14:24AM -0400, Randell Jesup wrote:
Hash tables are a big issue. There are a lot of 64K/128K/256K
allocations at the moment for hashtables. When we started looking at
this in bug 1436250, we had a 256K, ~4 128K, and a whole bunch of 64K
hashtable allocs (on linux).
>
>
>
> >Also note that dealing with the "importance" of a page is not just a
> >matter of visibility and focus. There are other factors to take into
> >account such as if the page is playing audio or video (like listening to
> >music on YouTube), if it's self-updating and so on.
>
> Absolutely
>
As a fyi there will be a tree closing window tomorrow July 14 06:00-15:00PDT
tldr: Trees will be closed for the duration of this maintenance,
bugzilla and mercurial will also be unavailable.
>From https://mozilla2.statuspage.io/incidents/980f0kzk533g
Impact to Users:
Trees will be closed
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1475605 to capture
this issue and (most of) this discussion.
On Tue, Jun 26, 2018 at 5:17 PM, Brannon Dorsey
wrote:
> >
> > First, I think downright denying "private IP addresses" from DNS
> responses
> > is very hard and is doomed to break
>On 13/07/2018 04:55, Randell Jesup wrote:
>> Correct - we need to have observers/what-have-you for
>> background/foreground state (and we may want an intermediate state or
>> two - foreground-but-not-focused (for example a visible window that
>> isn't the focused window); recently-in-foreground
>On Thu, Jul 12, 2018 at 08:56:28AM -0700, Andrew McCreight wrote:
>>On Thu, Jul 12, 2018 at 3:57 AM, Emilio Cobos Álvarez
>>wrote:
>>
>>> Just curious, is there a bug on file to measure excess capacity on
>>> nsTArrays and hash tables?
[snip]
>I kind of suspect that improving the storage
>On 05/07/2018 18:19, Mark Côté wrote:
>> I sympathize with the concerns here; however, changing the default would
>> be a very invasive change to Phabricator, which would not only be complex
>> to implement but troublesome to maintain, as we upgrade Phabricator every
>> week or two.
Makes sense.
This touches on a really important point: we're not the only ones
allocating memory.
Just a few that come to mind: GPU drivers, system media codecs, a11y
tools, and especially on Windows we have to deal with "utility"
applications, corporate-mandated gunk, and downright crapware.
When we're
Just another bit of info to raise awareness on a thorny issue we have to
face if we want to significantly raise the number of content processes.
On 64-bit Windows we often consume significantly more commit space than
physical memory. This consumption is currently unaccounted for in
about:memory
On 13/07/2018 04:55, Randell Jesup wrote:
> Correct - we need to have observers/what-have-you for
> background/foreground state (and we may want an intermediate state or
> two - foreground-but-not-focused (for example a visible window that
> isn't the focused window); recently-in-foreground
17 matches
Mail list logo
