Performance des frameworks
fouf
Membre
Bon après-midi à tous !
Ma question porte sur la vitesse des framework par rapport au code directement compilé dans l'appli elle-même. Qu'est ce qui est le plus rapide ? Combien de temps gagne-t-on en utilisant tel ou tel procédé ?
Merci d'avance :fouf):
Ma question porte sur la vitesse des framework par rapport au code directement compilé dans l'appli elle-même. Qu'est ce qui est le plus rapide ? Combien de temps gagne-t-on en utilisant tel ou tel procédé ?
Merci d'avance :fouf):
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
(static linkage VS. dynamic linkage) ?
Si c'est ça je ne pense pas que la différence de performance se fasse vraiment ressentir. Par contre le dynamic linkage a l'avantage d'utiliser un framework qui est partageable par tout le monde : ça évite d'avoir une copie du code (comme c'est le cas dans le static linkage) dans le programme compilé, mais ça oblige à ce que la personne ait aussi le framework à côté.
Dans le cas des frameworks standards Apple, aucun problème, tout le monde les a. Donc autant faire du dynamic linkage, ça fera une appli compilée moins grosse.
Dans le cas de frameworks de tierce partie, c'est kif kif, je pense.
Pour le launch-time, j'y ai pensé, mais l'update_prebinding est justement fait aussi pour ça. Donc du coup si le prebinding est bien fait (et il est fait à chaque installation d'un soft), le temps de lancement s'en voit réduit et pas si long.
Pour le cycle compliqué des fix/compile/link/debug, je ne suis pas d'accord : ce n'est pas du tout un argument pour ou contre les frameworks, mais pour ou contre le partage de ton code avec les autres !
A ce moment là les classes que tu redistribue sur ton site web sont aussi à proscrire, parce qu'elles ne sont peut-être plus compatible avec les évolutions de OSX ou de Xcode, etc... Et tout code que tu partages avec d'autres personnes aussi.
Quand on se dit "bon allez je me lance dans un framework" en général on le fait bien, et jusqu'au bout. Comme quand on se lance dans le design d'une classe qui a pour but d'être déployée, redistribuée à d'autres, et à vocation d'être publique.
Donc là , non, désolé, mais l'excuse n'est pas valable, elle ne décrédite pas le développement de frameworks persos, mais le partage de code.
Ou alors c'est que qqun qui ne sait pas forcément faire un code propre, générique, et réutilisable se lance dans la création d'un framework qu'il partagera avec d'autres, mais comme il aura pas bien codé ou pas rendu générique la chose, il aura plein de retours d'utilisateurs ;D
Pareil, pour le dernier argument, je ne vois pas trop le lien. Entre importer un framework de qqun qui a déjà implémenté tout ce qu'on voulait, ou recopier son code, ou le refaire soi-même... Je préfère importer le framework déjà fait, quitte à m'assurer que j'ai bien importé le truc. Ou alors quoi ? Je lui repique tout son code source et je refais donc la même chose ? Je fais le code moi-même, au risque d'oublier des cas particuliers auxquels le développeur du framework aurait pensé et pas moi ?
Bon je carricature, son argumentaire n'est pas non plus "développez chacun pour votre gueule", mais bon, include le code devant être partagé directement dans le projet, c'est bien pour des petits algos ou quoi, genre un bout de code pour calculer ci ou ça ou effectuer un truc un peu spécial.
Mais si c'est un truc générique (gestion des RegEx en Cocoa, gestion de MySQL, ce genre de trucs), je préfère un framework que repiquer du code, car franchement, là c'est clair qu'en repiquant les lignes de code par copier/coller d'un projet à un autre, le nombre de warnings et d'erreurs lors de la compilation risquera d'être élevé (car le code n'était pas spécialement prévu pour être publié et utilisé dans une autre appli), et le cycle de fix/compile/link/debug, pour le coup, est bien plus important qu'en utilisant un framework bien conçu (et surtout puisque c'est un framework, fait dans l'idée d'être utilisé par d'autres applis que celle pour laquelle il a été prévu initialement)