I’ve gotten good insight into what takes up space in binaries by profiling with Bloaty McBloatface. My last profiling session showed that clang’s ThinLTO was inlining too aggressively in some cases, causing functions that should be tiny to be 75 kB+.
Just a lot of flags that show you size by symbol in decimal with unmangled symbols. Run it before you run `strip` in your CI pipeline or whatever preps a build for proper release.
I agree, bloaty seems to be good in giving a good (and quick) overview but the difficult part is drilling through the symbols to find out what the heck is happening. In that case nm/objdump/readelf are irreplaceable.
If you can run PGO, it will take the profiling information into account when doing inlining heuristics, which can help a lot in some cases. Technically that is general optimization for speed and not size, though, so if you really care specifically for binary size you'd probably still have to muck about with noinline attributes and such.
Unfortunately, PGO done the default way is antithetical to reproducible builds. You can avoid that by putting the profiling data in your VCS, but then you suffer of all the consequences of a version-controlled binary blob, one heavily dependent on other files at that.
Perhaps it should be possible use profiling data to keep human-managed {un,}likely or {hot,cold} annotations up to date? How valuable are PGO’s frequencies compared to these discrete-valued labels? (I know GCC allows you to specify frequencies in the source, but that sounds less than convenient.)
When I worked on Matter a couple years ago, we had the problem that its backend http://www.capstone-engine.org/ did not support Xtensa, and produced some Python tools that could take output from bloaty or similar data from readelf or elftools, and produce several kinds of report.
The longevity diet identifies six steps designed to increase lifespan by promoting lean body mass and healthy blood sugar levels, switching off the body's central pro-ageing system and ramping up an anti-ageing process called
autophagy:
1. Limit calorie intake to maintain a body mass index of 22 to 23 for men and 21 to
22 for women.
2. Eat a diet high in wholegrains, legumes and nuts. Stop eating meat to restrict intake of the amino acid methionine, but include some fish.
3. Aim to get between 45 and 60 per cent of calories from non-refined complex carbohydrates, 10 to 15 per cent from plant-based proteins and 25 to 35 per cent from plant-based fats.
4. Do a limited daily fast, eating no calories from around 3 hours before bedtime and for the next 11 to 12 hours.
5. Every two to three months, undertake five days of a fasting-mimicking diet.
6. Alcohol is allowed in small amounts, but no more than 5 units a week.
We've been using Opera Critic (https://github.com/jensl/critic) where I work for about half a year. We did trial runs with Gerrit, Barkeep and Phabricator before settling on it. My impression is that its almost completely unknown outside of Opera, which is surprising given the feature set, clean UI and active development. The site used to review branches for the Critic project is also a demo: https://critic-review.org
It supports the model of having many atomic, reviewable commits on a topic branch. Where it seems to exceed Kiln is in the rebase/fixup workflow. You can push fixup commits in response to issues left by a reviewer. A fixup commit will automatically mark an issue it addresses as resolved when you push based on the lines it changes (the fixup must also be reviewed). You can later rebase the branch to integrate the fixups. It's pretty clever, and the way fixups are shown lets you see at a glance how the branch has evolved.
As a reviewer, and as someone who often digs through five year old commits, I want feature branches to follow the most linear path possible. Approaches that are started and abandoned, and commits made on top of a branch in response to review feedback are noise. A well-crafted branch often has little to do with what happened during development.
On another occasion, Lewin called Linux, which made servers in North Carolina, to say Akamai needed around 1,000 servers in four weeks. The company said such a large order wasn’t possible; they needed more time. Instead of pleading with them, Lewin sent them an e-mail to confirm a deadline of four weeks. That night, he went to the hardware store and bought tool kits, flew to North Carolina with some of his best engineers, and showed up to work at Linux the next morning. A baffled employee said, “Sir, who are you here to see?” Lewin replied: “I’m not here to see anyone; I’m here to build servers.” Within four weeks, he’d helped Linux construct more than 1,000 new servers.
This is the second time (to my knowledge, may have been going on for a while) that an Xcode beta has been made available to only one of the two (Mac and iOS) developer programs. The Xcode 4.3 beta was only available to iOS developers -- despite containing bug fixes and improvements useful to developers on both platforms. Now the Xcode 4.4 beta is only available to Mac developers.
I really don't see the logic in withholding from paying members of either platform.
You can't use the beta Xcode / SDKs to build apps for the relevant App Store anyway, so while it contains neat new features it's technically only useful for developers developing that particular pre-release OS (whether iOS 5.1 or OS X 10.8).
Interestingly now Xcode 4.3 is out of beta the iOS 5.1 SDK is still only available with Xcode 4.3 DP3 (although realistically there's not much public new stuff in iOS 5.1 since presumably it's all under wraps for the iPad 3).
Xcode 4.2 was also only available to iOS developers.
Xcode 4.1 was part of the Lion pre-release, so I don't think that iOS developers got it during beta, though apparently it was made available for SL users a few weeks after Lion shipped.
It at least makes sense to limit the betas to the Mac program only if the tool in question only works on a prerelease OS (I assume that's the case with 4.4 and ML). But limiting it to iOS developers only makes no technical sense at all.
Edit: 4.4 works on 10.7.3+, so yeah, this is just the usual bullshit.
I tried to get into Lucene (using SOLR) recently but was put off by it's complexity for what was, in my case, a simple use case (searching through a large document set of html, txt, and doc files quickly using proximity search).
After futzing for hours with XSLT and writing scripts to submit content via the REST API, I found out about FTS4 in SQLite, and was impressed by it's relative simplicity. I had something working in under an hour in Python.
This may be beyond your the scope of your needs but Riak Search <http://wiki.basho.com/Riak-Search.html>;
is pretty easy to use, is distributed and elastic. As a bonus you have Riak laying around if you need an awesome K/V store.
It's a quick, interesting, and to the point into to Riak, including theory, installation, and usage. The Basho guys have seriously great documentation, I've enjoyed browsing through the Riak wiki despite not really having any live Riak deployments.
I used SOLR for a site about a year ago, and I was absolutely shocked at how little documentation there was, and how low quality the existing documentation was. Everything was spread out over some awfully-maintained wiki that seemed to have no logical organization. Ugh, what a nightmare.
Jobs does use Mail (on both the iPhone and the Mac – as can be seen from examining the headers of his widely publicized emails)... and plenty of people aren't exactly fans of that application.
