[Android Builders Collective] Yank555:
This is indeed a different way to look at this and of course is very important. And certainly optimisations change the way the resulting binary code is generated, partially by making the code bigger, but avoiding jumping around in the binary code which can be bad in terms of CPU cache hit & miss ... I'm no expert in the details of this, last time I coded in assembler was on my Atari ST on its Motorola 68000 CPU when I was in high school (that's far far ... (damn !) ... so far back in time :D)

But different toolchains will also generate different code at the same optimizations, hence there IS a difference in the resulting binary files, and this is also what back then (stopped following this topic for quite some time) linaro clearly advertised. This is logical given the source code is first compiled into an object and then linked to become a binary executable on the given hardware. The linking process will use different binary codebits depending on the toolchain, hence the resulting binary code will be different.

Also optimization as well as toolchain do bear risks next to the advertised advantages, but as time goes by, code is cleaned up, making it easier to compile with higher toolchains / optimisation levels.

This is very obvious when you go from compiling a 3.0.y kernel to a 3.4.y or 3.10.y ... a lot of warnings are now considered errors, this forces devs to "keep their code cleaner" and that also is a good thing. When compiling a 3.0.y kernel (like for i9300), there are almost more warnings than files compiled, and on a 3.4.y kernel, there are just handfull of warnings left in the whole compile process.

(NB: ROM-side still has a huge number of warnings when compiling, and I suppose this work lies still ahead of us from that point of view.)

As to performance and stability, I have a different view on things, maybe a little less technical one for a change.

I try to stick closest to stock as a primary rule, the further you move away, the more you are likely to run into issues where there were none and tends to be timecomsuming to try to fix ...

... especially with the way I look at this :

To me, whatever is changed needs to bring actual day to day use advantages, no theoretical advantages like benchmarks, and also these advantages must not bring their share of issues, else I don't consider them an advantage anymore.

If a day to day use "feels" no different, I will always prefer to keep close to stock.

That is why I called these toolchains "fancy" which I admit was not a nice wording on my end, sorry for that "glitch" in my language :angel:

In essence, I am no advocate for "change just for the sake of changing", unless I see/feel a real difference, I don't see the need for change. As I consider all this (including coding) as just a means to an end, and the "shortest" way (as in the one with the least unnecessary complications) to achieve that goal is the one I will consider valid.

And this wasn't always the case, probably my age has changed my perception, while when I was young(er) I was rather obsessed by maximum optimization at everything coding related, by now (hitting 44), I don't quite see it that way anymore ... sure what I code I want (and try) to be the best possible (to my capacity, but who doesn't ?) but I will stop at that, and I will avoid making things more complex to go get that little extra drip of "whatever" and will rather prefer the code to stay simpler and easier to read and maintain.

Thus I will not like to code hacks (sure do on occasions, but only if it's temporary), like my "quest for the lost 5GHz WiFi channels" ... which I started in the ROM code and ended up fixing in the kernel, while at first I refused to add a "hack" to the kernel to force a country, I rather coded a country option in advanced WiFi settings in the ROM, to unfortunately later find out that wasn't fixing much, and so digging deeper I eventually found out that Google or Broadcom simply disabled those channels in the kernel, so I reenabled them, because that was the "shortest" way to fix that issue (and the proper one at that).

But again, as I said in an earlier post, we are not all made equal with equal ideas, wishes and needs, and the diversity here is so big that EVERYONE should find a shoe that fits him/her, and that is what I find so great about the builders collective, diversity ! ;)

JP.