(In reply to Doug Thayer [:dthayer] from comment #32)
Molly, does this sound insane?
Maybe a bit. ;) It's certainly a little unorthodox, but that's alright. One worry I have is that a disk defragmenter might come along and accidentally undo all this by relocating the file for its own purposes; I don't know how many systems run those things frequently anymore though.
Is there somewhere (the updater, or the maintenance service?) which would have the necessary privileges to do this?
Hmm, that leads to questions about where we put the code that does this work and when and how it gets run, there's gonna be a lot to talk about with that. There's explanations in here of a couple details that I know Doug already knows; just making sure everyone has the background.
For organizational purposes what I like the best would be to have the code live in the maintenance service (it runs as SYSTEM) and be invoked by starting it with a specific command. We could call that easily enough from both the installer and during a couple different phases of update (I'll get to that). The only problem there is the maintenance service is optional; you can choose to not install it at all, or to disable it by pref.
If we don't want to live with having to skip all this when the service isn't available, then putting the code in the updater would be an option, but I'd rather avoid adding the complexity there if possible. Other options would include a firefox.exe command-line parameter that only does this, or an entire bespoke binary. That also limits our options for when we run it to things that would already have elevation; I wouldn't want to have a UAC prompt show up just for this.
That does bring us to the question of when to call this code. Now, I'm assuming we can't do that while Firefox is running; I haven't checked, I don't know for sure, but rearranging files that have open handles sounds not good.
We would want to do this during initial installation I'd guess, but that's no problem, the installer can just kick it off as a normal install step.
Updates are an issue though; I'm also assuming we would need to run this on every update, because the parameters that determine what the right ordering actually is (i.e., what comes out of the PGO run) aren't predictable for a given build. If it runs very very fast, then we could always do this during the restart that applies the update, and that would be easy to do, but I'm afraid it won't be fast enough to make that work out.
I think the best option that leaves us is putting this at the end of staging an update; that's when we make a copy of the whole application and apply the new patch to the copy, all in the background while the now-old version is running, before prompting to restart. So we could apply this optimization to that copy right after we're done patching the files and before it gets moved into place to become the updated installation.
Occasionally in the past we have had to disable staging because of some instability around shutdown, but that's uncommon, and in that case we do the entire update process during the restart, all we've done already is download it, so that restart is gonna take a while anyway; maybe that means we could slot this thing in there.
Someday we'll have background updates too, that happen entirely while Firefox isn't running at all, and we can run this during those as well; there's not much to talk about there, I don't think it really adds more complexity.
Also note that not every installation ever gets admin privileges available to it (either because the user doesn't have them, or they just don't allow us to elevate), so this won't always be able to run anyway for that reason regardless of anything else.