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 fetch the
newest one.
The best way to fetch it is to pull the bookmark tracking it:
$ hg pull -B gps/build/measure-compiler
http://hg.gregoryszorc.com/gecko-collab
Or, look for that bookmark at
http://hg.gregoryszorc.com/gecko-collab/bookmarks and track down the
changeset.
(Also, while looking at the Mercurial source code to see if I could
expose hidden changesets through the web UI, I noticed that the official
resource/URL for linking to changesets is "changeset" not "rev." So, all
our Bugzilla URLs using /rev/<node> are using an alias. I'm curious if
this is intentional or an accident.)
On 11/25/13, 9:35 PM, Ehsan Akhgari wrote:
This patch doesn't seem to exist any more. Do you have another copy of
it lying somewhere?
Thanks!
--
Ehsan
<http://ehsanakhgari.org/>
On Fri, Nov 15, 2013 at 12:43 AM, Gregory Szorc <g...@mozilla.com
<mailto:g...@mozilla.com>> wrote:
C++ developers,
Over 90% of the CPU time required to build the tree is spent
compiling or linking C/C++. So, anything we can do to make that
faster will make the overall build faster.
I put together a quick patch [1] to make it rather simple to extract
compiler resource usage and very basic code metrics during builds.
Simply apply that patch and build with `mach build
--profile-compiler` and your machine will produce all kinds of
potentially interesting measurements. They will be stuffed into
objdir/.mozbuild/compilerprof/__. If you don't feel like waiting (it
will take about 5x longer than a regular build because it performs
separate preprocessing, ast, and codegen compiler invocations 3
times each), grab an archive of an OS X build I just performed from
[2] and extract it to objdir/.mozbuild/.
I put together an extremely simple `mach compiler-analyze` command
to sift through the results. e.g.
$ mach compiler-analyze preprocessor-relevant-lines
$ mach compiler-analyze codegen-sizes
$ mach compiler-analyze codegen-total-times
Just run `mach help compiler-analyze` to see the full list of what
can be printed. Or, write your own code to analyze the produced JSON
files.
I'm sure people who love getting down and dirty with C++ will be
interested in this data. I have no doubt that are compiler time and
code size wins waiting to be discovered through this data. We may
even uncover a perf issue or two. Who knows.
Here are some questions I have after casually looking at the data:
* The mean ratio of .o size to lines from preprocessor is 16.35
bytes/line. Why do 38/4916 (0.8%) files have a ratio over 100? Why
are a lot of these in js/ and gfx?
* What's in the 150 files that have 100k+ lines after preprocessing
that makes them so large?
* Why does lots of js/'s source code gravitate towards the "bad"
extreme for most of the metrics (code size, compiler time,
preprocessor size)?
Disclaimer: This patch is currently hacked together. If there is an
interest in getting this checked into the tree, I can clean it up
and do it. Just file a bug in Core :: Build Config and I'll make it
happen when I have time. Or, if an interested party wants to
champion getting it landed, I'll happily hand it off :)
[1] http://hg.gregoryszorc.com/__gecko-collab/rev/741f3074e313
<http://hg.gregoryszorc.com/gecko-collab/rev/741f3074e313>
[2] https://people.mozilla.org/~__gszorc/compiler_profiles.tar.__bz2
<https://people.mozilla.org/~gszorc/compiler_profiles.tar.bz2>
_________________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org>
https://lists.mozilla.org/__listinfo/dev-platform
<https://lists.mozilla.org/listinfo/dev-platform>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
