• [^] # Re: Et si le problème venait de Javascript lui-même ?

    Posté par . En réponse au journal JavaScript, performances, et Firefox. Évalué à 2.

    Pas forcement. Le langage ne précise pas si l'implémentation doit ou ne doit pas faire l'optimisation de récursion de queue. Parfois GHC la fait suivant le niveau d'optimisation (c'est systématique pour un appel récursif à main par exemple, pour une raison évidente). C'est pareil en C, il y a peu de langages qui précise que l'optimisation doit se faire. scheme est de ceux là, c'est le seul que je connaisse.

    f a = f a -- l'optimisation est faite même sans dire à ghc d'optimiser
    g a = g (a + 1) -- ghc optimise à partir de 01, ghc ici force l'évaluation du + pour pouvoir optimiser
    -- sans optimiser, g undefined remplit la pile de ((((undefined + 1) + 1) + 1)…
    -- en optimisant avec -O1, g undefined plante tout de suite
    
    

    L'optimisation de récursion de queue casse de fait les avantages de l'évaluation paresseuse, la mémorisation des résultats des appels par exemple. Calculer factorielle 100 quand on vient de calculer factorielle de 101 demande alors juste de regarder, avec l'optimisation il faut recommencer.

    Il y a des débordements de piles plus pernicieux lors que l'on traite de très grandes structures de données. Typiquement, vous voulez sommer les éléments d'une grande liste générée paresseusement. Le calcul de la somme si il n'est pas réalisé au fur et à mesure se retrouvera intégralement en mémoire, et sera effectué au dernier moment.

    Please do not feed the trolls