On 12-07-25 1:45 PM, Dave Mandelin wrote:
On Wednesday, July 25, 2012 7:45:43 AM UTC-7, Bobby Holley wrote:
On Wed, Jul 25, 2012 at 4:21 PM, Aryeh Gregor wrote:
gt; On Wednesday, July 25, 2012 3:04:31 PM UTC+3, Justin Lebar wrote:
gt; gt; amp;gt; The next step is to s/nsnull/nullptr/ in the
Hello everybody,
We have had a long history of using NSPR types such as PRInt32
everywhere on mozilla-central. This is no longer necessary as we have
decent support for stdint types in mozilla/StandardInteger.h. I have a
series of patches up for review on bug 579517 which switch us away
- ptrdiff_t
PRFloat64 - double
--
Ehsan
http://ehsanakhgari.org/
On Thu, Aug 9, 2012 at 11:57 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Hello everybody,
We have had a long history of using NSPR types such as PRInt32 everywhere on
mozilla-central. This is no longer necessary as we have
On 12-08-10 11:04 AM, Neil wrote:
Mike Hommey wrote:
That PRIntn is int is an implementation detail. The intent when using
int and int32_t/PRInt32 is different. We should keep it that way.
Yes, this is roughly what I was trying to say*, I just couldn't think of
the word intent at the time.
On 12-08-10 5:04 PM, Jason Smith wrote:
Hi Everyone,
Let's try posting this again. Disregard the comments I put on the other
thread.
I think this is a good time to re-think our process for testing for
something that is fixed or not fixed. I think a better approach that
maybe we need to
On 12-08-16 12:41 PM, Boris Zbarsky wrote:
On 8/16/12 12:07 PM, Ehsan Akhgari wrote:
I agree with Benjamin here. In fact, I think if we take out item 4
completely Aryeh's proposal still makes sense. Where the tests live in
our tree should not really matter.
It matters insofar as it makes
On 12-08-18 9:42 AM, ja...@hoppipolla.co.uk wrote:
On Friday, 17 August 2012 23:38:22 UTC+2, Justin Dolske wrote:
I'm talking about the problem of having a large set of tests with a
small percentage that fail intermittently, which is what we have today
in m-c. Even if they all magically
I suggest that the best place to develop this would be on
mozilla-central, especially since most of the work involved would
probably not be part of the build of any Tier 1 platform. This means
that you need to get reviews for the parts that touch things outside of
the widget back-end layer
On 12-08-21 4:37 PM, Kyle Huey wrote:
On Tue, Aug 21, 2012 at 1:09 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Any program which relies on an event loop is by definition going to suffer
from intermittent changes in behavior because of event ordering, etc. This
means that some tests
On 12-08-22 12:43 PM, Jeff Hammel wrote:
TL;DR - python if we want/need a full language, JSON if we can get away
with POD
I think JSON is the wrong choice here. It will not satisfy the need for
conditionals, which causes us to invent terrible hacks inside the JSON
like we had to do with the
On 12-08-29 8:10 PM, Justin Lebar wrote:
After getting an e-mail every single time m-c was merged for a day or
two, I filtered the e-mails and completely forgot about them. I
imagine most other people did the same. If we fix bug 752002, we'd
also need to change the e-mails so as to get around
On 12-08-30 5:42 PM, Taras Glek wrote:
* Joel will revisit maintaining Talos within mozilla-central to reduce
developer barriers to understanding what a particular Talos test result
means. This should also make Talos easier to run
I have filed bug 787200 for this discussion.
Ehsan
:14 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
If you haven't noticed it before, mozilla-central's git mirror has stopped
updating since some time yesterday after the IonMonkey merge. I've been
working on fixing it since last night when I was notified of the problem,
but that was a huge
On 12-09-13 6:30 PM, David Humphrey wrote:
Thanks for your work, Ehsan, it's really appreciated.
Can we file a bug on this and not have it be something literally off the
side of your desk? Too many of us depend on it now to not see this
through, and if you can't get it, we need to find another
This is a public service announcement to let you know that as of a few
minutes ago, I brought up the mozilla-central git mirror again. The
credit mostly goes to John Schoenick (johns) for telling me what was
wrong, and even giving me a script to fix it.
You can still find your favorite repo
On 12-09-14 11:54 AM, Ehsan Akhgari wrote:
On 12-09-14 10:51 AM, Mike Hommey wrote:
On Fri, Sep 14, 2012 at 08:41:19AM -0400, Ehsan Akhgari wrote:
OK, time for some good news. John Schoenick helped me yesterday on
IRC to understand what has caused this issue and how to fix it. I
tried
+1.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
The Valgrind builds on mozilla-central have been red for as long as I
remember. Does anyone care about them or should we just turn them off?
Thanks!
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 12-09-16 11:22 PM, Gary Kwong wrote:
I care about testing Firefox under valgrind, but if the valgrind
builds are
red and have been red for a long time there's no point in continuing
to run
them to see that they're still red.
They've been red for a long time partially because the Valgrind
I filed bug 792502 to kill FunctionTimer and friends.
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Aryeh has been doing a heroic job (I mean, heroic, for reals!) in bug
777292 to make nsresult a C++ enum, as opposed to just an unsigned int.
I've stepped in to help for the last few bits, and I'm planning to
land this work as soon as the (hopefully) final patch that I put up for
review gets
On 12-09-21 8:07 AM, Henri Sivonen wrote:
What's the type of nullptr on Mac OS X 10.7 debug build? On tryserver,
the compiler complains that there’s no nullptr_t in namespace std when
using std::nullptr_t. Including cstddef does not help.
MOZ_HAVE_CXX11_NULLPTR is defined, however.
Use case:
On 12-09-20 8:22 PM, Ehsan Akhgari wrote:
Aryeh has been doing a heroic job (I mean, heroic, for reals!) in bug
777292 to make nsresult a C++ enum, as opposed to just an unsigned int.
I've stepped in to help for the last few bits, and I'm planning to
land this work as soon as the (hopefully
Howdy all,
Josh Matthews has been helping a lot with the per-window private browsing
implementation that we have in the works. Throughout this effort, I
believe he has come to learn more about our private browsing implementation
than myself, so it's long overdue to announce him as the peer of
As of a few minutes ago, I've added 4 new branches to the git mirror at
https://github.com/mozilla/mozilla-central. The new branches are aurora,
beta, release and esr10, and they track the corresponding Mercurial
repositories. If you're using this mirror, here is a list of branches that
you
, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
As of a few minutes ago, I've added 4 new branches to the git mirror at
https://github.com/mozilla/mozilla-central. The new branches are aurora,
beta, release and esr10, and they track the corresponding Mercurial
repositories. If you're using
On 2012-10-01 12:27 PM, Nathan Froyd wrote:
I recently filed a bug (bug 792169) for adding NS_NewIMutableArray, in
service of deleting nsISupportsArray. The reviewer asked me to use
more standard C++ instead of perpetuating the NS_New* idiom and I did
so, with a static |Create| member function.
On 2012-09-30 2:47 AM, Justin Lebar wrote:
Unfortunately, due to https://bugzilla.mozilla.org/show_bug.cgi?id=767501,
the only way to get b2g builds on try is to use '-p all'.
Sounds like that should be a P1 for reducing load then.
Much-to-most of this B2G-only code compiles on other
Over in bug 796087, I'm proposing for us to remove the -t all try server
flag. The rationale is that the set of Talos tests vary greatly and most
of the people who test performance are only interested in a subset of Talos
tests. So I'm suggesting that we should disallow -t all as it is a very
On 2012-10-02 6:17 PM, Bobby Holley wrote:
The general problem as I see it is that talos try doesn't go orange if
there's a regression (because we detect regressions over time), and
checking the results against a baseline revision is kind of a pain, even
with talos-compare. So I think most
On 2012-10-02 6:00 PM, Karl Tomlinson wrote:
Ben Hearsum writes:
On 09/29/12 12:58 AM, Kannan Vijayan wrote:
1. A patch that is expected to succeed, but you want to run it through
try to verify.
For optimistic pushes, we expect that the patch goes from green =
green. For pessimistic
I believe this and other similar issues are being tracked by bug 795427.
Cheers,
Ehsan
On 2012-10-03 8:22 PM, Honza Bambas wrote:
So, another subject:
when I do a full build in parallel (win/pymake or using mach) and there
is some build error, it is always very hard to track the error down in
Public service announcement: the landing of changeset d81b605dc8d8 for
the recent WebRTC code will break your local checkouts if you're on Mac
or Windows because of a case folding issue. DO NOT pull from inbound
for now.
Ehsan
___
dev-platform
This is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=797910.
--
Ehsan
http://ehsanakhgari.org/
On Thu, Oct 4, 2012 at 12:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Public service announcement: the landing of changeset d81b605dc8d8 for the
recent WebRTC code will break your
OK, the situation is resolved, thanks to fox2mike, csheilds and bhearsum
and others. The below instructions still apply. Please ping me on IRC if
you hit problems.
--
Ehsan
http://ehsanakhgari.org/
On Thu, Oct 4, 2012 at 1:09 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
If you have any
On 2012-10-08 8:02 PM, Daniel Holbert wrote:
jgilbert points out that
- NS_ALWAYS_INLINE is broken in other ways as well (does absolutely
nothing on windows, even when paired with inline).
- there exists MOZ_ALWAYS_INLINE which does this right.
So, we should probably just get rid of
On 2012-10-11 3:16 PM, Randell Jesup wrote:
In Bug 794510, ehsan said in response to me:
Isaac makes a good point; we should clearly mark imported code, both for our
own purposes and for scripts. Biesi and I were commiserating about the lack of
a standard for this (third_party/blah such as
On 2012-10-11 6:36 PM, Mike Hommey wrote:
On Thu, Oct 11, 2012 at 06:14:51PM -0400, Ted Mielczarek wrote:
On Thu, Oct 11, 2012 at 4:20 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
What I really don't want us to do is to prohibit people from fixing things
in the imported code
On 2012-10-11 4:34 PM, Mike Hommey wrote:
On Thu, Oct 11, 2012 at 02:26:33PM -0400, Rafael Ávila de Espíndola wrote:
On 10/11/2012 02:33 AM, Mike Hommey wrote:
On Wed, Oct 10, 2012 at 05:57:53PM -0400, Justin Lebar wrote:
By turning off Linux PGO testing, you really mean stop making and
On 2012-10-11 8:52 PM, Wan-Teh Chang wrote:
Ehsan wrote:
It is entirely unreasonable to render ourselves unable to modify
our imported code (just look at the current situation with NSPR
which causes developers to go through huge pain in order to work
around things which would be very simply
For the past few months, Aryeh has been doing a heroic work on making
nsresult a strongly typed enum (aka, enum class). Strongly typed enums
are a new feature in C++11 which enable declaring enums which are
treated as real types by the compiler and go through similar type
checking as other
On 2012-10-15 5:32 PM, Robert O'Callahan wrote:
On Tue, Oct 16, 2012 at 4:18 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Sure, I was not suggesting that. What I was suggesting was to take our
implementation of the TimeStamp class for Windows and use the same ideas in
the NSPR
Hi everyone,
As part of our efforts to get more value out of the Talos test suite for
preventing performance regressions, we believe that we are now ready to put
a first set of measures against startup time regressions. We will start by
imposing a new backout policy for mozilla-inbound checkins
On 2012-10-19 11:39 AM, Armen Zambrano G. wrote:
Is there a place where this will be document?
I would like to keep an eye on what gets added or point people at it.
Not that I know of! Please feel free to start a wiki page or something.
;-)
Ehsan
On 2012-10-19 12:13 PM, Dao wrote:
On 18.10.2012 20:05, Ehsan Akhgari wrote:
If your patch falls in a range which
causes more than 4% Ts regression, it will be backed out by our sheriffs
together with the rest of the patches in that range, and you can only
reland after you fix the regression
I'd like to switch our coding style to use #pragma once instead of #include
guards. #pragma once is supported on all compilers than can build our
source code, it is more concise, and it avoids possible name clashes in
#include guards (or adopting silly conventions for avoiding them), and it
can
On 2012-10-29 7:56 PM, Justin Lebar wrote:
Not a concern, but the obvious question is: Do you have any idea how
this affects compile times?
It probably won't have any meaningful improvements, since all decent
compilers already seem to special case #include guards.
Ehsan
On 2012-10-29 9:11 PM, Gregory Szorc wrote:
On 10/29/12 5:52 PM, Robert O'Callahan wrote:
On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote
n.netherc...@gmail.com
wrote:
#pragma once does have one drawback (other than being non-standard)
and that is if you have the same file in different
I have documented this here:
https://developer.mozilla.org/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities#Dealing_with_performance_regressions
--
Ehsan
http://ehsanakhgari.org/
On Thu, Oct 18, 2012 at 2:05 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Hi everyone
On 2012-11-01 9:19 PM, Dave Mandelin wrote:
(a) How about building Windows with a newer version of MSVC, say 2012? (What
version are we using now, anyway? The build instructions page says 2010 is
official, but a tbpl log showed Visual Studio 9.0 on the path.) Maybe they have
fixed bugs in
On 2012-11-01 8:47 PM, Dave Mandelin wrote:
|-- tests/
|-- browser-chrome/
|-- topic1 (omit this level if there would be only one)
|-- topic2
|-- [...]
|-- chrome/
|-- crashtests/
|-- marionette/
|--
Hi all,
The building where the machine hosting the git mirror updater is located is
going under a power maintenance tomorrow, Nov 3, from 8am - 4pm eastern
time. Therefore, the git mirror may not get updated in that period. Once
the power comes back up, the service should resume.
Apologies in
On 2012-11-08 1:44 AM, Henri Sivonen wrote:
On Thu, Nov 8, 2012 at 12:03 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
How does this proposal address the question of partially implemented
features?
If we consider a partial feature ready for use by Web developers, then
we could ship
On 2012-11-09 1:28 PM, Kyle Huey wrote:
I reviewed a patch today that had:
using namespace mozilla;
using namespace dom;
The intent is to pull in the contents of both the mozilla and mozilla::dom
namespaces, but this is only clear if you know that there is no top-level
dom namespace. In the
On 2012-11-09 2:43 AM, Henri Sivonen wrote:
Hmm, well, a partial feature might be considered useful for web developers,
but still finishing the implementation may mean changing the way that the
partial implementation works later on, which is likely to break stuff that
rely on it. I'm not sure
On 2012-11-09 3:40 PM, Chris Peterson wrote:
On 11/9/12 11:53 AM, Ehsan Akhgari wrote:
using namespace mozilla;
using namespace mozilla::dom;
The style guidelines recommend against using nested namespaces, so doing
what you suggest would make them self-inconsistent.
But we have some nested
On 2012-11-13 9:56 AM, Jonathan Kew wrote:
On 12/11/12 15:47, Alex Keybl wrote:
Bug 799295 [1], the driver for this thread, is still an open issue for
FF18 (shipping in 6 weeks). The JS team's recommendation remains to
disable PGO on Linux. According to Taras, the major benefits of PGO on
Linux
On 2012-11-26 7:17 AM, smaug wrote:
As a reviewer and someone who cares about quality, this annoys me
because I know
it is something that could largely be solved through decent automation
and tools.
Yes. We certainly should have at least coding style checker, and uuid
update checker.
On 2012-11-30 12:16 PM, Henri Sivonen wrote:
On Tue, Nov 27, 2012 at 6:59 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2012-11-27 3:49 AM, Henri Sivonen wrote:
So I adjust my policy proposal to:
Therefore, I propose that we adopt the following policy:
1) APIs that are shipped
On 2012-12-06 10:11 PM, Chris Peterson wrote:
For example, someone who downloads Firefox's Portuguese build is
probably interested in ECMAScript internationalization, but only as it
pertains to Portuguese.
There is nothing special about a Portuguese build compared to, let's
say, an English US
On 2012-12-07 1:54 PM, Benoit Girard wrote:
Is there an API we can query to know what the estimated wait time or load
for a slave pool is? Perhaps 'http://trychooser.pub.build.mozilla.org/'
could be modified to give an indication of the load for a particular
platform. I would be more mindful at
On 2012-12-28 5:34 PM, Boris Zbarsky wrote:
On 12/28/12 2:00 PM, Neil wrote:
But if you're keeping nsIDOMNode, then you might as well keep the most
popular interface that derives from it.
Probably true, unless we decide we don't care _that_ much about editor
perf and move it to a tearoff
On 2013-01-03 1:28 PM, Benjamin Smedberg wrote:
On 1/3/13 1:23 PM, Boris Zbarsky wrote:
On 1/3/13 1:08 PM, Benjamin Smedberg wrote:
Do we know why this was happening? The log module specifies nsDebug,
and it should only be written to the log if PR_LOG_MODULES includes
nsDebug.
It's because
Can you please add code snippets on that page to show how this API can
be used to solve some example problems? It would really help if those
problems are the sort of things that actually come up in the Mozilla
code base. I have a really hard time inferring how the API is supposed
to be used
Hi all,
Currently, DONTBUILD only takes affect if it's set on the tip of the
changesets that you push. This can cause problems when merging between
different trees if the target tree is a full subset of the origin tree
(i.e., fast-forward merges in git terminology) when the top-most changeset
is
The Aurora tree was closed yesterday by Ed because of the perma-orange
failure filed in bug 823989, which went unnoticed for quite some time
before Ed closed the tree. This morning, I tried to reproduce the bug
locally using the information posted on there and I saw that it was easily
They define MOZ_UPDATE_CHANNEL=aurora which causes the testpilot extension
to be built among other things.
Cheers,
Ehsan
On 2013-01-17 10:20 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/17/13 6:21 PM, Ed Morley wrote:
On 17 January 2013 22:58:20, Ehsan Akhgari wrote:
The Aurora tree
On Fri, Jan 18, 2013 at 5:39 AM, L. David Baron dba...@dbaron.org wrote:
So given that this is a regression in Firefox 19 (which is now on
beta), and the only reason we're not seeing this permaorange on beta
is because we don't generate non-debug nightly builds on beta (and I
don't think we
On 2013-01-18 11:03 AM, Justin Lebar wrote:
Fri, Jan 18, 2013 at 10:35 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On Fri, Jan 18, 2013 at 5:39 AM, L. David Baron dba...@dbaron.org wrote:
So given that this is a regression in Firefox 19 (which is now on
beta), and the only reason we're
On 2013-01-18 11:35 AM, Justin Lebar wrote:
To restate dbaron's argument in my own words:
1. There is a known issue affecting both beta and aurora nightly builds.
2. Either the issue is or isn't serious enough to warrant closing the
aurora tree.
3. If it is serious enough to warrant
On 2013-01-18 10:35 AM, Ehsan Akhgari wrote:
On related news, this thread diverged into multiple different private
threads, and it seems like the devtools team has two patches in bugs
824016 and 774619 which can probably help. I have asked them to land
both patches as they don't require
On Fri, Jan 18, 2013 at 1:50 PM, L. David Baron dba...@dbaron.org wrote:
On Friday 2013-01-18 11:49 -0500, Ehsan Akhgari wrote:
I see. I think your assumption in point #2 above is mistaken. We
do not close trees because of the gravity of issues affecting the
code base. We do close them
dbaron posted a summary of our options on release-drivers. He and I
recommended disabling the testpilot extension completely as a solution.
I guess we'll wait until somebody approves doing that.
Cheers,
Ehsan
___
dev-platform mailing list
I'm sorry that I have to be the bearer of bad news about our trees, but
we have finally started to hit the linker maximum memory size when
linking libxul as part of our Windows PGO builds, and as a result,
mozilla-central and inbound are CLOSED for now.
I propose the following:
1.
Status update: we have landed three patches on mozilla-inbound which
disable PGO on the following directories (rdf/, image/ and accessible/)
and I have triggered PGO builds on top of them to see how much they can
shave off of the linker's vmem usage. Randel is also working on taking
some
to
disable PGO on them:
https://hg.mozilla.org/integration/mozilla-inbound/file/357b9a855e10/rdf/defs.mk
).
Thanks!
--
Ehsan
http://ehsanakhgari.org/
On Mon, Jan 21, 2013 at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Status update: we have landed three patches on mozilla-inbound which
,
--
Ehsan
http://ehsanakhgari.org/
On Mon, Jan 21, 2013 at 11:32 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Second status update:
The numbers from disabling PGO on image, accessible and webrtc are in, and
the linker max vmem size is down by only ~200MB, which is quite
disappointing
On Tue, Jan 22, 2013 at 7:35 AM, Mike Hommey m...@glandium.org wrote:
On Tue, Jan 22, 2013 at 01:30:50PM +0100, Mike Hommey wrote:
On Mon, Jan 21, 2013 at 11:32:34PM -0500, Ehsan Akhgari wrote:
Second status update:
The numbers from disabling PGO on image, accessible and webrtc
On 2013-01-22 9:45 AM, Marco Bonardo wrote:
On 22/01/2013 15:36, Benjamin Smedberg wrote:
On 1/22/2013 9:28 AM, Axel Hecht wrote:
How are the perf numbers looking?
One of the reasons for asking is that I expect RDF to be part of the
startup and window-open codepaths, at least.
I would not
OK, everyone. Both mozilla-central and mozilla-inbound are *temporarily*
reopened now. Please be gentle.
Cheers,
--
Ehsan
http://ehsanakhgari.org/
On Tue, Jan 22, 2013 at 9:06 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Status update #3:
It seems like with PGO disabled for all
On 2013-01-22 4:40 PM, Robert O'Callahan wrote:
On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
But note that unless a given code path is examined throughout the
profiling phase of a PGO build, PGO will probably have
Hi everyone,
I have started an effort to gather some information on what options we
have with regard to using PGO on Windows in the longer term, in the
hopes that we won't be surprised by PGO build bustages any more. I have
filed bug 833881 to track this effort, and have filed various
On 2013-01-23 3:38 PM, Joe Drew wrote:
On 2013-01-22 5:27 PM, Mike Hommey wrote:
FWIW, IIRC my experiments last time we had this problem, LTCG alone
accounts for less than a third of the performance boost we get from
PGO on Talos.
Did you happen to measure how big the linker got in memory
On 2013-01-28 3:38 AM, Brian Smith wrote:
Ehsan Akhgari wrote:
I have started an effort to gather some information on what options
we have with regard to using PGO on Windows in the longer term[.]
If you have ideas
which are not covered by the bugs on file, please do let me know
On 2013-01-28 12:48 AM, Brian Smith wrote:
Joshua Cranmer wrote:
In bug 732043, I want to add a mozilla::Atomic class
that lets us use C++11 atomics where available and fallback to
compiler intrinsics where C++11 atomics are not implemented
(which amounts to gcc 4.4 and Visual Studio 2010 or
On 2013-01-28 7:11 PM, Brian Smith wrote:
[+taras]
Kyle Huey wrote:
2. Because NSS reads and writes to files in the profile directory,
the profile directory must be readable and writable up until process
exit. The current rules for XPCOM shutdown say that services must
stop doing disk I/O well
On 2013-01-30 11:38 AM, Kevin Brosnan wrote:
Does this remove any of the use cases? Such as the -private or
-private-toggle command line flag or the never remember history setting.
This is not going to change any of the features that are enabled in
Nightly now. I was just removing a whole
(Follow-ups to dev-platform, please)
Dear all,
This email summarizes the results of our investigation on our options
with regard to the future of PGO optimizations on Windows. I will first
describe the work that happened as part of the investigation, and will
then propose a set of options
On 2013-01-30 11:11 PM, Robert O'Callahan wrote:
What about leaving PGO/LTCG enabled for a subset of our modules? Is that
not a possible solution?
I did in fact measure that by disabling PGO/LTCG on all directories
except content, dom, layout and xpcom. I can't seem to find the try
push
On 2013-01-30 11:40 PM, Robert O'Callahan wrote:
On Thu, Jan 31, 2013 at 5:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
On 2013-01-30 11:11 PM, Robert O'Callahan wrote:
What about leaving PGO/LTCG enabled for a subset of our modules
On 2013-01-31 3:37 AM, Nicholas Nethercote wrote:
On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Given the above, I'd like to propose the following long-term solutions:
1. Disable PGO/LTCG now.
2. Try to delay disabling PGO/LTCG as much as possible.
3. Try
On 2013-01-31 5:38 AM, Neil wrote:
smaug wrote:
On 01/31/2013 10:37 AM, Nicholas Nethercote wrote:
If we know we're going to turn it off, why not bite the bullet and do
it now?
Because we're still missing plenty of optimizations in our code to be
fast in microbenchmarks.
Do we know (e.g.
On 2013-01-31 6:39 AM, jmath...@mozilla.com wrote:
We then tried to get a sense of how much of a win the PGO optimizations
are. Thanks to a series of measurements by dmandelin, we know that
disabling PGO/LTCG will result in a regression of about 10-20% on
benchmarks which examine DOM and layout
On 2013-01-31 10:33 AM, Till Schneidereit wrote:
In the long run, 1 and 3 are the same. If we know we're going to turn
it off, why not bite the bullet and do it now?
Because we're still missing plenty of optimizations in our code
to be fast in microbenchmarks. It would be quite huge pr loss
On 2013-01-31 11:43 AM, Kyle Huey wrote:
On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
We then tried to get a sense of how much of a win the PGO
optimizations are. Thanks to a series of measurements by dmandelin,
we
On 2013-01-31 10:59 AM, jmath...@mozilla.com wrote:
As a historical note, when we first enabled PGO support for Windows our
profiling scenario was start Firefox, wait 10 seconds, shut down
Firefox. Enabling PGO with this profiling run provided us with 20-25%
perf improvements in many of our
On 2013-01-31 11:58 AM, Kyle Huey wrote:
On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
On 2013-01-31 11:43 AM, Kyle Huey wrote:
Isn't PGO worth something like 15% on Ts?
That was what I thought, but local
On Thu, Jan 31, 2013 at 12:12 PM, Kyle Huey m...@kylehuey.com wrote:
On Thu, Jan 31, 2013 at 9:09 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-01-31 11:58 AM, Kyle Huey wrote:
On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhgari@gmail.**com
On 2013-01-31 2:49 PM, David Anderson wrote:
On Thursday, January 31, 2013 8:54:50 AM UTC-8, Ehsan Akhgari wrote:
On 2013-01-31 10:59 AM, ... wrote:
As a historical note, when we first enabled PGO support for Windows our
profiling scenario was start Firefox, wait 10 seconds, shut down
On Fri, Feb 1, 2013 at 10:19 PM, Brian Smith bsm...@mozilla.com wrote:
Ehsan Akhgari wrote:
Given the above, I'd like to propose the following long-term
solutions:
1. Did we try escalating a support request to Microsoft regarding this
issue? I know it is kind of an odd thing, but it seems
1 - 100 of 1215 matches
Mail list logo
