1396084 - Investigate skipping pdb compression during build, making symbol server do it

Status: NEW

(Firefox Build System :: General, enhancement)

Description

[(not currently active) Ted Mielczarek]

We spend a bunch of time during the build compressing PDB files with makecab so that they're smaller for developers to download when debugging. This is generally pretty important--a recent Nightly xul.pdb I downloaded is 176MB compressed, and 632MB uncompressed.

However, when we upload the symbols to the symbol server, we stick them all in a zip anyway, and the symbol server already does some work to gzip-compress .sym files before storing them in s3 (so they can be served with Content-Encoding: gzip), so maybe we can just put the .pdb files directly in the zip, and make the symbol server run makecab on them before putting them in s3.

Since the zip is compressed anyway they should compress roughly the same amount. We're using MS-ZIP compression with makecab, which is just DEFLATE the same as zip.

Comment 1

[Gregory Szorc [:gps]]

My recollection of the times involved is that this could save dozens of seconds of CPU for builds. Just as long as the compression isn't done at HTTP request time as part of the upload.

Comment 2

[(not currently active) Ted Mielczarek]

Symbol uploads are done as a separate post-upload task anyway, but AFAIK peterbe said that the .sym compression + upload to s3 happens asynchronously after a zip file POST is accepted.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

Is there any interest in doing this still? There's no priority set, so I think the answer is "not really".

I ask because I'm triaging the Symbols bugs and one of them blocks this one and if this one isn't going to be worked on, then I'll close mine out.

Comment 4

[(Away)]

(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #3)

Is there any interest in doing this still? There's no priority set, so I think the answer is "not really".

I think gsvelto would have the best picture of what the current situation looks like.

Comment 5

[Gabriele Svelto [:gsvelto]]

Yes, this sounds like something useful. But it should happen on the build side. The only thing we'd have to do server-side is to check that the resulting files haven't grown too much if we don't compress them beforehand.

Comment 6

[(Away)]

IIUC, this would let us remove all references to makecab from the tree? That would be some nice cleanup.

Comment 7

[(not currently active) Ted Mielczarek]

(In reply to Gabriele Svelto [:gsvelto] from comment #5)

Yes, this sounds like something useful. But it should happen on the build side. The only thing we'd have to do server-side is to check that the resulting files haven't grown too much if we don't compress them beforehand.

I"m curious as to what you mean by "on the build side"? Currently the compression happens during the build task itself as part of symbolstore.py. This bug proposes moving the compression to Tecken in between "accept a zip file" and "upload each item to S3", like how it already gzip compresses .sym files. Adding this to the symbol upload task would be a net loss because we optimized that by allowing Tecken to accept a URL to a symbols.zip, so the symbol upload task doesn't ever touch the actual symbols, it simply POSTs the URL to the symbols.zip artifact from the build.

Comment 8

[Mike Hommey [:glandium]]

See the commit message in https://phabricator.services.mozilla.com/D85250

Comment 9

[Gabriele Svelto [:gsvelto]]

(In reply to (not currently active) Ted Mielczarek from comment #7)

I"m curious as to what you mean by "on the build side"? Currently the compression happens during the build task itself as part of symbolstore.py. This bug proposes moving the compression to Tecken in between "accept a zip file" and "upload each item to S3", like how it already gzip compresses .sym files. Adding this to the symbol upload task would be a net loss because we optimized that by allowing Tecken to accept a URL to a symbols.zip, so the symbol upload task doesn't ever touch the actual symbols, it simply POSTs the URL to the symbols.zip artifact from the build.

I think I meant that we shouldn't compress the symbols with makecab in the (local) build but honestly I'm not sure I remember what my reasoning was at the time. It seems Mike found another solution in the meantime.