fuchsia-binary-size failure for seemingly-trivial change

[Greg Thompson]

Hi Fuchsia friends. https://crrev.com/c/7455767 is a pretty trivial CL that changes calls of the form:

  sql::Statement::BindInt64(N, something that gets the internal value of a base::Time)

to:

  sql::Statement::BindTime(N, a base::Time)

(and similar for base::TimeDelta.)

I am bit surprised to see that this is increasing the size of web_engine and chrome_fuchsia so much (the same patch set succeeded on Jan 16 here). My guess is that this very small change bumps something just over some threshold so that code now spills over into a new page or somesuch.

May I safely ignore this?

Interestingly, the uncompressed size is up 20KB while the compressed size is up 32KB. Is that expected from whatever compression we're doing? Seems kinda like expansion to my eyes. :-)

Thanks for the help.

[Greg Thompson]

The CL passed the bot a few hours later, so this is no longer an issue for me. I'm still curious about what happened, though. Thanks.

Greg

[Wez]

My guess would be that it's a mixture of the subtle changes in calling code (e.g. one of the call-sites now does a Time->TimeDelta->Time computation where previously it just treated the TimeDelta directly as an int64), and the introduction of callers for SqlStatement::BindTimeDelta(), which AFAICT wasn't previously used.  And yeah, those are probably such tiny impacts that you just got unlucky with it tipping things over some "page" threshold in the linker?

--
You received this message because you are subscribed to the Google Groups "fuchsia-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fuchsia-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/fuchsia-dev/CAKQnr0QayikSQriNV25yZ0sv-emEm5G%3DN1nw54qvpLR8ucnSDw%40mail.gmail.com.

[Zijie He]

+1 to Wez, the latest iteration showed 24576 compressed size increment with zero uncompressed size.

Early this month, Colin suggested https://crrev.com/c/7396986 to loosen the binary size restriction, so <32K compressed size increment won't trigger an error anymore. But compression is a little bit magic and can cause increment without uncompressed size change. 😅

        .Hzj_jie