Salut,
Super_Cinci:
Il ne fait rien du tout, mais l'idée était de voir comment l'IDE allait me traiter tout ça. alors je suis allé chercher le fichier Hex qu'il m'a pondu, et je l'ai décortiqué à l'aide de ReAVR, un petit soft qui transforme les .hex en assembleur. Je ne vous donne pas tout le code asm, mais j'ai fini par retrouver mon setup() et loop() dedans.
Il ne fait pas "rien du tout".
Il places les broches n°1, 3, 5, 7 du port F en sorties et les autres en entrées, puis fait passer la broche n°0 du port F d'entrée à sortie indéfiniment.
Même si ce n'est pas grand chose ça reste quelque chose 
Super_Cinci:
J'y ai surtout vu ce que le core arduino rajoutait, comme l'interruption du timer0 pour le comptage de milliseconds(), et je peux vous dire que cette interruption, elle prend beaucoup de place, juste pour incrémenter une variable de type long (4 octets) en SRAM...
Ce qui est tout à fait normal ...
Le code source de l'interruption du timer0 est conçu pour maintenir à jour une variable de temps en millisecondes ... mais pas que.
Cette interruption a aussi pour but de maintenir à jour un compteur de temps très précis en fraction de millisecondes pour la fonction micros().
C'est pour cela qu'elle peut te paraitre assez volumineuse, mais en réalité elle fait pas mal de chose.
(voir dans le fichier wiring.c)
Super_Cinci:
Puis j'ai aussi vu la façon dont le compilateur compilait, ben c'est bien loin d'être optimisé! Si on fait deux opérations à suivre sur un même registre, il va aller copier ce registre, faire l'opération, le remettre à sa place, puis le reprendre et faire la seconde opération et enfin le remettre à sa place. ce n'est qu'une des nombreuses bourdes que j'ai relevées... si j'ai le temps, je ferai la même chose avec un digitalWrite() pour voir... 
Tu mélanges tout
Il faut bien différencier l'optimisation du code source (par le dév) et l'optimisation du compilateur (par le compilateur et le linker).
L'ide Arduino est paramétré pour ne demander quasiment aucune optimisation au compilateur par défaut.
De même l'ide Arduino ne peut pas corriger les décisions d'analyses et de conceptions de la team arduino.
Il faut aussi prendre en compte un point TRÈS important : le framework Arduino N'EST PAS conçu pour la vitesse / optimisation / etc.
Il est conçu pour être simple d'utilisation par des novices de la programmation, l'optique Arduino c'est "je tapote, ça marche, fini".
C'est dure à dire mais c'est comme ça.
En aucun cas l'optimisation n'as été une fonctionnalité du core arduino
digitalWrite() en interne c'est 6 appels de fonction, 3 tables de lookup en flash et 440 octets de code machine (environ).
Ça semble énorme comparé à un pauvre PORTx |= _BV(PINx); qui demande 8 octets de code machine mais c'est comme ça.
L'optimisation a été volontairement sacrifié au profit de la simplicité.
Après il existe des initiatives comme "DigitalWriteFast" qui se basent sur des #define et de l'optimisation en pré-compilation mais le résultat reste le même : dés qu'on retombe sur un digitalWriteFast(valeur_dynamique) on revient aux 6 appels de fonctions, 3 tables, etc
Abstraction matériel haut niveau et optimisation intensive bas niveau ne peuvent malheureusement pas cohabiter.
Il faut faire un choix à un moment donné.
Super_Cinci:
Je me suis amusé à réécrire le code asm sur une petite partie, et surprise : entre ce que le core arduino dit en C et l'assembleur que je ponds, il y a un rapport 2 (mon code est deux fois plus court, donc deux fois plus rapide). 
Fait un test, compile ceci avec l'ide Arduino :
int main() {
DDRF = 0xAA;
for(;;)
DDRF = !DDRF;
}
L'ide Arduino est conçu pour passer en mode "éditeur de texte" dés qu'une fonction main() existe.
Le code ci dessus est donc un code Arduino tout à fait valable, mais regarde la taille du programme générait.
Le facteur de taille doit être d'environ /3
Super_Cinci:
Bref, CDG = Coup De Gueule ]
: d'une, le core est très mal écrit, et de deux, le compilateur n'optimise pas si bien que ça...
Le core Arduino est assez mal écrit, c'est un fait mais :
- n'oublions pas que la team Arduino à l'origine est composée de designer. C'est déjà pas mal qu'ils aient pu apprendre la programmation Java et AVR-C.
(même si c'est vrai qu'ils auraient pu laisser la prog à des développeurs compétent, bref)
- le compilateur optimise très bien ... quand on lui demande
GCC est un compilateur dont le taux d'optimisation est très élevé (si bien utilisé). GCC en mesure de générer du code machine avec seulement 10% d'instructions en plus par rapport à un code assembleur fait main par un "pro".
(PS: depuis les nouvelles formes d'optimisation "LTO" ce % à du diminuer drastiquement)
- le compilateur AVR-GCC fourni avec l'ide à plus de 4 ans de retard (et même si beaucoup de monde râle la team Arduino s'en fout royalement)
- l'ide arduino est un gouffre sans fond en terme de truc foireux mais ça tout le monde le sait
Donc oui je te comprend mais il faut relativiser.
Si tu veut du code optimiser il ne faut pas espérer des miracles
Moi je code désormais exclusivement en AVR-C, mes programmes ont perdu un sacré poids sans pour autant être plus compliqué à lire.
Mais bien sûr pour coder en AVR-C il faut lire la doc constructeur en anglais, du coup les débutants prennent peur.
Même si le core arduino est une catastrophe en terme d'optimisation cela reste un excellent moyen de commencer dans la programmation embarqué.
Après il faut savoir évoluer et passer à quelque chose de mieux une fois les bases acquises.
Super_Cinci:
Ce qui me pousse de plus en plus à revoir entièrement les choses en créant mon propre core... et ça ne va pas tarder...
Beaucoup ont essayé, et crois moi c'est pas aussi simple que ça n'y parait
Faire quelque choses de simple, optimisé et portable demande beaucoup de réflexion et une analyse en béton armé.
Ps: je sait pas si c'est la crève ou quoi mais j'étais inspiré dis donc, désolé pour le roman