hannes/hannes.robur.coop
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

.

Browse source
This commit is contained in:
Hannes Mehnert 2016-06-11 19:53:17 +01:00
parent cb71f67479
commit 5472f1b2dd
1 changed files with 4 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
Posts/BottomUp
View file

@ -98,8 +98,12 @@ Besides the hello world, I used the same tools on our [BTC Piñata](http://ownme
[<img src="https://www.cl.cam.ac.uk/~hm519/pinata-bytes.svg" title="Piñata byte sizes" width="700" />](https://www.cl.cam.ac.uk/~hm519/pinata-bytes.svg) [<img src="https://www.cl.cam.ac.uk/~hm519/pinata-bytes.svg" title="Piñata byte sizes" width="700" />](https://www.cl.cam.ac.uk/~hm519/pinata-bytes.svg)
### Conclusion
OCaml does not yet do dead code elimination, but there [is a PR](https://github.com/ocaml/ocaml/pull/608) based on the flambda middle-end which does so. I haven't yet investigated numbers using that branch. OCaml does not yet do dead code elimination, but there [is a PR](https://github.com/ocaml/ocaml/pull/608) based on the flambda middle-end which does so. I haven't yet investigated numbers using that branch.
Those counting statistics could go into more detail (e.g. using `nm` to count the sizes of concrete symbols - which opens the possibility to see which symbols are present in the objects, but not in the final binary). Also, collecting the numbers for each module in a library would be great to have. In the end, it would be great to easily spot the source fragments which are responsible for a huge binary size (and getting rid of them).
I'm interested in feedback, either via I'm interested in feedback, either via
[twitter](https://twitter.com/h4nnes) or as an issue on the [data repository on [twitter](https://twitter.com/h4nnes) or as an issue on the [data repository on
GitHub](https://github.com/hannesm/hannes.nqsb.io/issues). GitHub](https://github.com/hannesm/hannes.nqsb.io/issues).