In addition to what Yang says: We have - at around the same time - added an
API to explicitly set the snapshot + natives sources (
V8::Set(Natives|Snapshot)DataBlobg in include/v8.h), so any embedder can
use whichever compression they want at the price of a bit more boilerplate.

In other words:
- Previously, the data was embedded in the v8 lib, and the embedder used
#ifdef to tell V8 (at compile time) which compression to use.
- Now, you can instead embed them into the embedder library, compressed in
whichever way you want; then compress them at startup and pass them
uncompressed to V8. That's the same thing that happened before, except now
the (de-) compression happens on your side of the fence.


On Wed, Oct 12, 2016 at 10:14 AM, Yang Guo <yang...@chromium.org> wrote:

> It was unused, and the trade-off of saving space on the disk and the
> additional time and memory we would need for unzipping is not something we
> want to make.
> Besides, there are plans to not ship js sources at all anymore.
> Cheers,
> Yang
> On Wed, Oct 12, 2016, 10:12 <lifeoftha...@gmail.com> wrote:
>> Hello, vogelheim.
>> It's old thread. But,
>> can I ask why this happens?
>> I think the compression gives benefit in some cases.
>> Is there any reason to rip out the compression related codes?
>> https://codereview.chromium.org/750543002/

v8-dev mailing list
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to