• [^] # Re: Survivor

    Posté par . En réponse au journal C, un âge remarquable. Évalué à 4.

    C’est pas si compliqué que ça.
    Soit tu travaille des byte streams sans te poser la question des encodages et de la semantique des bytes, et Swift te donne cette possibilité, C aussi d’ailleurs.

    Soit tu travailles sur des chaînes de caractères et t’es un peu obligé de prendre en compte la normalisation Unicode si tu veux émettre du code correct. Swift te donne cette possibilité. C aussi d’ailleurs, mais tu vas avoir beaucoup plus de boulot à faire.

    C’est surtout ça qui m’ennuie dans ton commentaire, considérer qu’une String est juste un tableau d’octets. C’était vaguement vrai en 1977, mais ça fait plus de 20 ans que ça n’est plus le cas.

    La question est surtout est ce que ton code est correct? Parce qu’aller très vite pour donner la mauvaise réponse, c’est facile, je peux le faire moi aussi: 42, temps constant, je suis le plus rapide de la planète.
    Ok, j’exagère un peu. Plus sérieusement, un lookup qui foire dans une hash map pour des raisons d’encodage de la clé, c’est quand même super ballot. Idem pour une recherche dans un index full text, ou un sed qui rate une substitution.

    T’imputes aussi une perte de performance à cette normalisation sans avoir la moindre idée du coût réel de cette normalisation.

    Est ce que Swift est « plus lent » que du C? Oui, très probablement.
    Dans quelle proportion est il plus lent? Ça depend du contexte.
    Est ce que cette lenteur est causée par la normalisation? Probablement pas, en tout cas certainement pas au niveau que tu penses.