toi, t'as déjà tenté d'utiliser un truc genre Poseidon UML !
HS
la différence entre une String et un StringBuffer
tu parles du truc qui synchronize je-sais-pas-quoi ? levez la main ce qui utilise un StringBuffer en parallèle !
Quant à la diff String/StringBuffer, je te répondrais que c'est le boulot du compilo ou de la VM. Python2.4 a retravaillé ce genre de chose, et des boucles
while machin:
s = s + "truc"
sont maintenant optimisés je sais pas comment, mais au final les performances sont quasi-linéaires. J'avais testé, il faut des tailles de chaînes de plusieurs Mio pour que l'utilisation d'un StringIO (équivalent du StringBuilder) commence à devenir plus avantageuse (contre ~4Kio avec python2.3). Bref l'utilisation des StringIO devient marginale, sauf quand fonctionnellement c'est plus adapté. Les développeurs python sont également plus habitués au meilleur "truc".join(liste)
[^] # Re: Y a comme un problème ....
Posté par TazForEver . En réponse à la dépêche Appel à contribution sur GanttProject. Évalué à 3.
HS
la différence entre une String et un StringBuffer
tu parles du truc qui synchronize je-sais-pas-quoi ? levez la main ce qui utilise un StringBuffer en parallèle !
Quant à la diff String/StringBuffer, je te répondrais que c'est le boulot du compilo ou de la VM. Python2.4 a retravaillé ce genre de chose, et des boucles
while machin:
s = s + "truc"
sont maintenant optimisés je sais pas comment, mais au final les performances sont quasi-linéaires. J'avais testé, il faut des tailles de chaînes de plusieurs Mio pour que l'utilisation d'un StringIO (équivalent du StringBuilder) commence à devenir plus avantageuse (contre ~4Kio avec python2.3). Bref l'utilisation des StringIO devient marginale, sauf quand fonctionnellement c'est plus adapté. Les développeurs python sont également plus habitués au meilleur "truc".join(liste)
Donc pour moi c'est un faux problème.