Re: To what extent is sccache's distributed compilation usable?
> On 29. Oct 2019, at 18:53, Steve Fink wrote: > > On 10/28/19 9:17 PM, Marcos Caceres wrote: >> On Tuesday, October 29, 2019 at 3:27:52 AM UTC+11, smaug wrote: >>> Quite often one has just a laptop. Not compiling tons of Rust stuff all the >>> time would be really nice. >>> (I haven't figured out when stylo decides to recompile itself - it seems to >>> be somewhat random.) >> Probably a gross misunderstanding on my part, but the sccache project page >> states [1]: "It is used as a compiler wrapper and avoids compilation when >> possible, storing a cache in a remote storage using the Amazon Simple Cloud >> Storage Service (S3) API, the Google Cloud Storage (GCS) API, or Redis." >> >> I'm still (possibly naively) imagining that we will leverage the "the >> cloud"™️ to speed up compiles? Or am I totally misreading what the above is >> saying? >> >> [1] https://github.com/mozilla/sccache#sccache---shared-compilation-cache > > My experience with other distributed compilation tools (distcc, icecc) > indicates that cloud resources are going to be of very limited use here. > Compiles are just way too sensitive to network bandwidth and latency, > especially when compiling with debuginfo which tends to be extremely large. > Even if the network transfer takes way less time than the compile, the > sending/receiving scheduling never seems to work out very well and things > collapse down to a trickle. > > Also, I've had very limited luck with using slow local machines. A CPU is not > a CPU -- even on a local gigabit network, farming off compiles to slow > machines is more likely to slow things down than speed them up. Despite the > fancy graphical tools, I was never completely satisfied with my understanding > of exactly why that is. It could be that a lack of parallelism meant that > everything ended up repeatedly waiting on the slow machine to finish the last > file in a directory (or whatever your boundary of parallelism is). Or it > could be network contention, especially when your object files have massive > debuginfo portions. (I always wanted to have a way to generate split > debuginfo, and not block on the debuginfo transfers.) The tools tended to > show things working great for a while, and then slowing down to a snail's > pace. This research offers some insight: https://www.usenix.org/system/files/atc19-fouladi.pdf / https://github.com/StanfordSNR/gg In particular: > Existing remote compilation systems, including distcc and icecc, send data > between a master node and the workers frequently during the build. These > systems perform best on a local network, and add substantial latency when > building on more remote servers in the cloud. In contrast, gg uploads all the > build input once and executes and exchanges data purely within the cloud, > reducing the effects of network latency. Their system using 8000 AWS Lambdas is 2x faster than an icecc cluster when building Chromium, although that is still a *remote* icecc cluster. Maybe the speedup is less significant with a local cluster like we're running in our offices. -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
On Nov 25, 2014, at 13:22, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: On 25/11/2014 14:22, rayna...@gmail.com wrote: I need to get the audio sample data and do some math on it, then play it in the speaker, with the minimum of latency (arround 20ms). Only the wasapi driver could allow this. Have you actually tried using getusermedia/web audio for this? Or are you just speculating? What does the wasapi driver provide that the web's APIs don’t? Low latency. I’m no audio expert, but my understanding is that a 20ms round-trip is _very_ fast. See: https://wiki.mozilla.org/Media/WebRTC_Audio_Issues#Audio_Latency_--_bug_785584 https://wiki.mozilla.org/Gecko:MediaStreamLatency#Windows -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed changes to autocomplete administrative levels
On May 15, 2014, at 9:29, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 14, 2014 at 1:52 AM, Brian Nicholson bnichol...@mozilla.com wrote: If we disagree with this proposal: What alternatives do we have? Given that countries require more than two administrative levels in postal address, it seems our options are limited. We can't simply provide a single blob for an entire address as sites generally require more tokenized information. You do not want to tie this to a particular localization. E.g. I use the en-US version of Firefox, but I make payments with European credit cards. Localization should not affect functionality. I don’t think that’s even possible. As Brian said: In short, every localizer would need to be able to translate every other countries' administrative levels. The en-US locale (and every other locale) would need to have English translations for European countries’ administrative level names. -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Always brace your ifs
On Feb 22, 2014, at 16:53, Mike Hoye mh...@mozilla.com wrote: On 2/22/2014, 1:04 PM, Jet Villegas wrote: goto ftw; I have to admit, I was very surprised to learn that: - Using both -Wall and -Wextra doesn't get you -Wunreachable-code. - The Clang manual lists documenting any of that that as a todo. -Weverything ftw. -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable autoplay feature of HTMLMediaElement on mobile?
On Dec 9, 2013, at 19:17, Chris Pearce cpea...@mozilla.com wrote: On 12/10/2013 4:38 AM, Henri Sivonen wrote: On Sun, Dec 8, 2013 at 11:49 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think it's important to have an easy way to mute/unmute the browser, but disabling autoplay is probably not the right way to address these issues. A pref to disable autoplay might be, though. We have this, set media.autoplay.enabled to false. Note that B2G doesn't have an about:config. -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On Oct 29, 2013, at 12:23 PM, Doug Turner doug.tur...@gmail.com wrote: Nothing. Just time. Patches accepted. Not really? Last time I looked into this one of the problems was that AlertsService exposes an alertfinished event (for when the notification goes away) that we can’t implement when using NC, since NC notifications go to the Notification Center when the user doesn't interact with them. That means we can’t implement alertclickcallback consistently either – alertclickcallback needs to fire before alertfinished. I don't know if 10.9 exposes a new API to detect when a notification was removed from the notification center. -- reuben smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Please specify if a clobber is Windows only in the CLOBBER file
In my experience, most of the recent changes to CLOBBER have been made to fix Windows-only build system bugs. It'd be helpful to people working on Linux and OS X if you could include in the CLOBBER file whether the clobber is only needed on Windows. (That way you can do |cd $OBJDIR touch CLOBBER cd - ./mach build| to ignore it) Thanks! -- reuben smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript Style Guide. Emacs mode line.
On Sep 11, 2013, at 12:04 PM, Scott Johnson sjohn...@mozilla.com wrote: I understand the merit of leaving the code as is since hg blame won't work nicely with such file-wide format change as in step-1. (Or maybe we can teach hg blame to ignore such change, etc. but maybe too much work: the idea would be to mark formatting change with a particular string [maybe tag name] and let hg blame to ignore such tag to look for a previous patch that touched each line. Hmm. Maybe too much work indeed) It would be really nice if we could somehow teach hg blame to ignore style changes, but I think that's probably a very involved task. ;) Mercurial is very extensible, the easy way to do this is to simply flag style changing commits with metadata and then use that during blame. -- reuben smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting the current release version
On Aug 30, 2013, at 1:35 PM, Eric Shepherd esheph...@mozilla.com wrote: On 2013-08-30 16:13:50 +, Jesper Kristensen said: I use http://svn.mozilla.org/libs/product-details/json/firefox_versions.json I use that because that was what the download button on www.mozilla.org did. I don't know if the download button still uses that resource. This is an interesting tidbit. Anyone know where that comes from and if it's a reliable source? http://svn.mozilla.org/libs/product-details/README CC'ing clouserw for details. -- reuben smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: smartmake-like functionality has landed in mach
On May 3, 2013, at 8:53 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2013-05-03 3:21 AM, Mike Hommey wrote: On Fri, May 03, 2013 at 02:55:09AM -0400, Ehsan Akhgari wrote: Does it also build browser/app on OSX after every build? Since that is pretty much required all the time and often missed. Why is that always required? I never build browser/app and have not noticed any problems at least for Gecko changes. If you run from dist/bin, it's not required. It is if you run dist/Nightly.app or whatever it's called. It's also required for make package to work. I've never run my builds from dist/bin. I don't think this is a requirement for anything that doesn't touch omni.ja stuff Exactly, that's the case where you need to rebuild browser/app, omni.ja stuff. , since libxul is a symlink to the binary in objdir/toolkit/library, for example: $ ls -l obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/ ... lrwxr-xr-x1 ehsanakhgari staff 70 3 May 01:01 XUL - /Users/ehsanakhgari/moz/mozilla-central/obj-ff-dbg/toolkit/library/XUL You can also use |ac_add_options --with-chrome-format=symlink| to do something similar for the chrome JAR, it doesn't work with stuff that is preprocessed, but greatly reduces the number of files that require rebuildling browser/app when changed. -- reuben___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
We use IndexedDB extensively in a lot of the WebAPIs, see Contacts, Settings, SMS, MMS, Push, NetworkStats… Right now there's a lot of boilerplate[1] involved in setting up IndexedDB, and people end up duplicating a lot of the boilerplate code. It'd be great to see a more polished wrapper around it. The callback chains of death involved in writing IDB code are also not very pleasant to read and write, so bonus points if we could have a syntax like Task.jsm, where you can do |result = yield objStore.get(foo);| I don't know how much of this overlaps with the work to expose a simpler KV-store like API for saving snippets of data, but I figured I'd mention that this is also a problem for consumers wh need all the functionality of IDB. [1] http://mxr.mozilla.org/mozilla-central/source/dom/base/IndexedDBHelper.jsm -- reuben___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of MOZ_MAKE_FLAGS Considered Unnecessary
On Nov 29, 2012, at 10:10 AM, Mounir Lamouri mou...@lamouri.fr wrote: If you really want to get rid of MOZ_MAKE_FLAGS, maybe you could add a new variable to just set the -j value with a default to N if most people thing this is the best value. +1. I often switch between -j4 and -j2 because the former makes my computer unusable during the build. Being able to do |./mach build -jN| would be useful. -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
