undefined | Better HN

0 pointstakeda7y ago0 comments

You have it backwards, apache or nginx size is not for the novelty. Go is just a pig and its size grows every new release, and the size isn't really for being statically linked or debugging symbols, because it's huge even when those options are disabled.

Right now a "hello world" application in Go has comparable size to an OS with full GUI.

0 comments

9 comments · 2 top-level

sagichmal7y ago· 4 in thread

Who cares? Literally, what problem does it cause, or what does it make worse? It is totally immaterial.

takedaOP7y ago

- increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it)

- it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly)

- it increases amount of data transferred on every deployment

- increases amount of memory used (the whole point of containers, was to efficiently use hardware (BORG), although a lot of people today miss that reason and run containers on VMs)

yetanotherme7y ago

True. Luckily, most Go binaries can be upx'd ( https://upx.github.io/ ) for a fraction of their original size. Just put it into your Dockerfile as a part of the build process.

2 more replies

TickleSteve7y ago

You have to ask yourself what is that space used for??

They're all compiled languages doing (roughly) the same operations. There is an order of magnitude difference in the number of instructions in one compared to the other.

Apache is more likely to be entirely cached whereas the others aren't.

Size matters for performance.... if you're not CPU bound, fine, but to say its immaterial is naive.

xg157y ago

Even if we don't know which particular problem it might cause right now, being wasteful when you can avoid it is never a good idea.

Image size is currently not the most important metric, but - guessing how your average node.js package already looks today - demanding people ignore it completely will probably set you on the road of multi TB images that also contain the developer's favorite desktop environment in the medium future.

chx7y ago· 3 in thread

You would need find an application where the binary image size is a problem. In an age where 1TB SSDs are 300 USD this will be ... challenging. You are able to have about a thousand gigabyte sized images on that one SSD and I suspect you will hit CPU and I/O limits well before you have a thousand different binaries running for real.

Media storage would go on spinning rust disks anyways separate from the SSD(s).

derefr7y ago

The consideration isn’t binary size, but hot-loop cache coherency. Big binaries cause code-segment cache-line eviction.

nolok7y ago

Then that's a typical case of optimizing on the wrong metric.

Find a case where it's actually too slow, ok, but saying "A does X, and X can lead to Y, therefore A does Y" is wrong.

If you say the size of the binary is an issue, then give the issue, not how it could (or not) be an issue.

takedaOP7y ago

We observed noticeable difference in deployment time and auto scaling based on container size.

j / k navigate · click thread line to collapse

0 comments

9 comments · 2 top-level

sagichmal7y ago· 4 in thread

Who cares? Literally, what problem does it cause, or what does it make worse? It is totally immaterial.

takedaOP7y ago

- increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it)

- it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly)

- it increases amount of data transferred on every deployment

- increases amount of memory used (the whole point of containers, was to efficiently use hardware (BORG), although a lot of people today miss that reason and run containers on VMs)

yetanotherme7y ago

True. Luckily, most Go binaries can be upx'd ( https://upx.github.io/ ) for a fraction of their original size. Just put it into your Dockerfile as a part of the build process.

2 more replies

TickleSteve7y ago

You have to ask yourself what is that space used for??

They're all compiled languages doing (roughly) the same operations. There is an order of magnitude difference in the number of instructions in one compared to the other.

Apache is more likely to be entirely cached whereas the others aren't.

Size matters for performance.... if you're not CPU bound, fine, but to say its immaterial is naive.

xg157y ago

Even if we don't know which particular problem it might cause right now, being wasteful when you can avoid it is never a good idea.

chx7y ago· 3 in thread

Media storage would go on spinning rust disks anyways separate from the SSD(s).

derefr7y ago

The consideration isn’t binary size, but hot-loop cache coherency. Big binaries cause code-segment cache-line eviction.

nolok7y ago

Then that's a typical case of optimizing on the wrong metric.

Find a case where it's actually too slow, ok, but saying "A does X, and X can lead to Y, therefore A does Y" is wrong.

If you say the size of the binary is an issue, then give the issue, not how it could (or not) be an issue.

takedaOP7y ago

We observed noticeable difference in deployment time and auto scaling based on container size.

j / k navigate · click thread line to collapse