gmane.comp.mozilla.performance

Re: Shutting down dev.performance

Taras Glek — 2011-11-29T18:28:04

Thanks to Ehsan for reminder, 
https://bugzilla.mozilla.org/show_bug.cgi?id=706152

Re: Shutting down dev.performance

Armen Zambrano G. — 2011-11-29T14:45:55

I found this mailing list by mistake and I had never heard of it.
I agree with Taras as nothing has been posted in here since August 
(except Rob Helmer).

BTW most perf regressions found on the tree are reported on 
dev.tree-management.
We also have discussions on how to improve things over there with the 
A-team.

Not sure if I just misunderstand the purpose of this mailing list.

cheers,
Armen


On 11-08-25 12:11 PM, Taras Glek wrote:

what should the defaults on the graphs-new dashboard be?

Robert Helmer — 2011-11-03T01:45:34

Hello,

Right now http://graphs-new.mozilla.org/ shows some defaults we randomly 
picked out over a year ago:

* Platforms: Windows 7 and XP, Mac OS X, Linux
* Products: Firefox, Tracemonkey or Places (default to Firefox)
* Tests: Ts (startup time), Tp (pageload), SunSpider

I was starting to work on adding a separate Mobile "product" to the 
pulldown, but perhaps it makes more sense to just add Android to the 
front page (which defaults to Firefox)? Technically, Talos reports these 
as "mobile" not "firefox" but one of the goals of the new interface is 
to make performance data more useful and accessible.

You will still of course be able to multi-select any combination of 
graphs you like at http://graphs-new.mozilla.org/graph.html this is just 
about the fast-loading front-page dashboard.


Thanks!
Rob

Re: what should the defaults on the graphs-new dashboard be?

Robert Helmer — 2011-11-03T01:48:24

Oops, this should have gone to m.d.platform; please ignore and follow up 
on the equiv thread there. Thanks!

Re: Shutting down dev.performance

Robert O'Callahan — 2011-08-25T21:24:20


Just ignore/mute/kill the threads you don't care about, right? I know some
people have difficulty doing that due to, um, client limitations, but
old-skool newsreaders should be fine.

I find it both essential (across many mailing lists and newsgroups, not just
Mozilla's) and trivial to ignore threads I'm not following. (I use Gmail but
that's not the only option.)

Rob

Re: Shutting down dev.performance

Mike Shaver — 2011-08-25T21:00:25

We created a list for b2g to solve that; apologies for not doing that
sooner, it was certainly pretty disruptive for other platform
conversations.

I don't think it makes sense to split performance out into a separate
area of discussion.  It's not really a separable concern: it needs to
be part of how we think of everything we do, and improvements in it
will always involve one or more other domains.  Similarly with
security.

It might be that performance tools could be in another group, but I
think they're low enough volume that it's not worth adding another
channel to monitor or find, and also the audience for those tools is
everyone, so other than really specific architectural issues it's
going to want lots of platform feedback anyway.


I think a media list makes more sense, since it's a vertical rather
than horizontal area of work.

Mike

Re: Shutting down dev.performance

Boris Zbarsky — 2011-08-25T19:24:00

Most likely because they use the mailing list, not the newsgroup, and 
you didn't set a Reply-To header and the gateway is dumb and doesn't 
turn Followup-To into Reply-To and vice versa....

-Boris

Re: Shutting down dev.performance

Randell Jesup — 2011-08-25T17:00:31

My mistake was cross-posting it to .platform... :-)


Actually, I do object.  The most interesting discussions from my posting
came in .performance, and quite honestly I'd have preferred for all
discussion of it to have been there - I was just worried that perhaps no one
was monitoring it, as I'd been away for a while, and wanted to 'ping'
people in platform to look here.  Unfortunately, various people's
newsreaders (or people purposely) sent replies to .platform instead of
honoring the Followups-To.  (Thunderbird bug, perhaps?)

m.d.platform is already an over-full group with insufficient breakout
IMHO - it gets overwhelmed occasionally by stuff like B2G.  Part of the
problem may be that people have moved away from "traditional"
newsreaders.

Bugs aren't a great place for discussion.  Newsgroups are (and I'd love
more broken-out specialization); or the modern equivalent to newsgroups
(web forums, though for many uses I prefer newsgroups to web forums, not
the least of which is that *I* get to decide what m

Re: Shutting down dev.performance

Chris Ilias — 2011-08-25T16:43:47

https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Discussion%20Forums

Shutting down dev.performance

Taras Glek — 2011-08-25T16:11:30

Hi,
At the moment dev.performance is a little used list that overlaps with 
dev.platform. Important recent posts made on dev.performance, have been 
a mistake (eg. threads by Messrs. Jesup and Mandelin). So in order to 
not risk further lost threads I propose we shutdown this mailing list 
and move all of the future discussion to dev.platform.

Any objections?

Rob Helmer, the sole regular user of the list doesn't have any 
objections, anybody else?

Tips on the process for closing a newsgroup?

Taras

Android/ARM Firefox Performance: where we are and where to go

David Mandelin — 2011-08-23T00:27:09

I've been thinking a bit about what can do, and what we need to do, for
Firefox performance on mobile devices. This is really just a start, but
I think it points the way for the performance efforts we have to make to
make Firefox just as great on Android/ARM as it is on desktop. I give an
evaluation of performance today, recommendations for top performance
goals, some big changes we might need, and last, a draft plan, really
just a sketch, of the way forward.

Dave

0. Summary

If you have a powerful device, Firefox performance is in many ways
pretty good. But UI responsiveness and memory usage seem to be in pretty
bad shape, although they are hard to measure. So we need to get better
measurements and start improving performance in those areas, today.

If you don't have a powerful device, things are worse. General
improvements--especially in memory, the prime suspect--should help us
there. But I think we also need to get the message out about what kinds
of hardware give a good Firefox experience, so that we

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Taras Glek — 2011-08-17T17:59:37

So just to clarify. Conceptually it may be the same as a db. In practice 
keeping independent items in a file is a very bad idea. Ie if you have 7 
tabs saved and then you close tab 3, you get in an ugly situation.
A database will try to pretend it's ok at expense of serious 
fragmentation, requiring a vacuum, etc.

I think a sessionrestore directory with a json(or something else) per 
tab is the only sane solution here. Let the filesystem do what it's good at.

The other benefit of file-per-tab is that they can be fsynced 
independently without blocking io on other tab stores.


First step should be adding telemetry to record sizes of json files and 
time to read/write them.

Taras

graphs-new change - render points instead of lines in custom chartview

Robert Helmer — 2011-08-08T18:29:49

Hello,

A graphs-new.mozilla.org release will be pushed shortly (bug 677309). 
This contains fixes for things like links to mozilla-inbound, showing 
the right version of Tp on the dashboard, and fixes for a few small bugs.

I don't normally post about new releases here, but this also includes a 
UI change from Justin Lebar to show points instead of lines on the 
Custom Chart view (example: 
http://graphs.allizom.org/graph.html#tests=[[16,63,12]]&sel=1307933238936,1308631085090&displayrange=90&datatype=running 
) so I wanted to call that out specifically.

Thanks to Justin for this contribution, hopefully it makes graphs more 
useful for everyone. I'd be interested in any feedback.


Thanks,
Rob

Re: Howto disable gecko's GTK themeing?

JacquelinePOWERS — 2011-07-20T06:54:13

freelance writer

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Joshua Cranmer — 2011-07-19T22:35:16

LevelDB is designed to sensibly handle values from the small sizes to 
multi-GB per value, or so I am told.

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Randell Jesup — 2011-07-19T21:29:16

Right - I didn't know the E10s architecture yet (on my list...) ;-)


[ Hi Mike. Long time no chat  :-) ]

That can be done with many of these ideas, especially the DB-based ones. 
  And file-per-tab is pretty much the same as a DB, it's just 
filesystem-as-dumb-DB.  :-)  Not that it's necessarily bad.

Kyle (in .platform - that will teach me to cross-post) and Taras 
suggested LevelDB over SQLite (we don't really need much in the way of 
complexity here, mostly just safety against crashes and large blob 
storage - which may speak to files, since filesystems are good at that).

An intern has expressed interest in trying some of the options proposed.
I dropped some dumb testcode in the bug to help.

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Randell Jesup — 2011-07-19T21:18:43

I cross-posted this at first since .performance seemed pretty quiet 
recently, but I think it makes sense for future comments to all be there 
if people don't mind.

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Boris Zbarsky — 2011-07-19T15:49:47

Across an upgrade, yes.  Across downgrades, no, but that's because I 
never downgrade.  ;)

-Boris

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Mike Shaver — 2011-07-19T15:47:07

Across upgrades, though?

Mike

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Mike Shaver — 2011-07-19T15:46:21

IMO, that's not really OK long term (e10s-term) -- the tabs will need
to report their state back to chrome, so that the blocking goes the
other way.


File-per-tab containing all the data for that tab, maybe?  Or two
files per tab, to avoid re-writing the big sessionstorage data every
time, if it doesn't change that often.  This would let us write out
the current tab more frequently than background tabs, as well.

Mike

Re: SessionStore size - Bloat in sessionstore.js from Google andothers causing major UI freezes

Boris Zbarsky — 2011-07-19T15:41:59

This is arguably a mistake....

I know I treat _my_ saved sessions as precious data.

-Boris