Non (je crois qu')il n'y a pas d'incidence sur la mémoire.
Si j'ai bien retenu ce que j'avais lu à l'époque, la lenteur viendrait du linkage dynamique des libs relatives au c++ utilisé par KDE qui serait assez lent et provoquerait un gros temps de latence.
Donc je ne crois pas qu'il y ait des composants qui reste en mémoire, mais peut etre que les binaires / libs etc. sont un peu plus gros.
Il me semblait que quand on compilait avec l'objprelink, Konqueror crashait assez lamentablement dès qu'il y avait un peu de javascript.
Si c'est plus le cas, alors je me demande pourquoi les packages de kde pour sid sont compilés sans (vu que kde met plus de 30s a demarrer sur mon athlon xp flambant neuf avec tout plein de ram j'en conclue qu'il est compilé sans).
[^] # Re: bonne idée
Posté par f l . En réponse à la dépêche Compiler et optimiser KDE 2.2.2. Évalué à 1.
§6: An Option For The Speed Obsessed
27 Jul Archive Link: Faster startups by fixing C++ object files before linking (new version and results)
[^] # Re: bonne idée
Posté par f l . En réponse à la dépêche Compiler et optimiser KDE 2.2.2. Évalué à 10.
Si j'ai bien retenu ce que j'avais lu à l'époque, la lenteur viendrait du linkage dynamique des libs relatives au c++ utilisé par KDE qui serait assez lent et provoquerait un gros temps de latence.
Donc je ne crois pas qu'il y ait des composants qui reste en mémoire, mais peut etre que les binaires / libs etc. sont un peu plus gros.
# Javascript
Posté par f l . En réponse à la dépêche Compiler et optimiser KDE 2.2.2. Évalué à 1.
Si c'est plus le cas, alors je me demande pourquoi les packages de kde pour sid sont compilés sans (vu que kde met plus de 30s a demarrer sur mon athlon xp flambant neuf avec tout plein de ram j'en conclue qu'il est compilé sans).