Usterka pamięci w jQuery UI Draggable z MeteorJS?

Question

Wydaje mi się, że odkryłem przeciek pamięci w bibliotece, która może być przeciągnięta przez interfejs jQuery UI, chociaż problem może być spowodowany przez Meteor, nie jestem pewien.

Najpierw zauważyłem to, gdy moja aplikacja była przez cały dzień używana przez grupę użytkowników. Miałem otwartą aplikację w zakładce i do końca dnia było tak wolno, że nie można jej było używać. Sprawdziłem zużycie pamięci i zauważyłem, że zużywa ona prawie całe GB pamięci.

Aby odtworzyć ten numer, napisałem skrypt PhantomJS, który loguje się do aplikacji i wykonuje kilka aktualizacji, rejestrując użycie pamięci w narzędziach programistycznych Chrome. Poszukałem więc kodu, który spowodował problem, i odkryłem, że były to zdarzenia, które można przeciągać i upuszczać, w których umieszczałem elementy w zdarzeniu renderowania mojego szablonu.

Oto przykład użycia pamięci podczas gdy mój skrypt phantom biegnie z przeciągany:

i tu jest moje zużycie pamięci bez Draggable:

UWAGA: Próbowałem Draggable & droppable razem, jak a także osobno, z opcjami konfiguracji ZERO i nie stwierdzono zauważalnych zmian w wycieku.

Jak wynika z pierwszego wykresu, użycie pamięci nie jest zwalniane po zatrzymaniu się skryptu (około 1,4 min), a zużycie pamięci jest dość duże (od 14,3 MB do 169 MB). To trwa około 300-500 aktualizacji (coś, co prawdopodobnie nie jest wcale nierealistyczne, zwłaszcza w ciągu całego dnia z dużą liczbą użytkowników).

Myślę, że kluczem tutaj jest liczba węzłów, którą Chrome daje na karcie osi czasu. Po uruchomieniu skryptu jest 100 000 węzłów DOM zgodnie z liczbą węzłów DOM, po drugiej jest ich około 1000.

Stworzyłem całkowicie niezależny projekt, aby zapewnić ten problem. Położyłem to na github, aby każdy mógł się z nim bawić. Mój skrypt phantomJS znajduje się w katalogu głównym.

https://github.com/davidworkman9/jQueryDraggableMemLeakWithMeteor

jestem pewny gdzie iść stąd, czy meteor lub jQuery UI, lub jeśli problem jest rozwiązywalne bez poprawki od jednego z tych pakietów.

Answer 1

Dla każdego, kto cierpi na ten problem, zaprojektowałem tymczasową poprawkę (działa to dla każdego ponownego renderowania szablonu).

(function() { 
    var oldRender = Spark.renderToRange; 
    Spark.renderToRange = function (range, htmlFunc) { 
     var oldFunc = htmlFunc; 
     htmlFunc = function() { 

      // put in clean up code here Example: 
      if(range._start === $('#myTemplate')[0]) { 
       $('#myTemplate').find('.ui-draggable').draggable('destroy'); 
      } 
      // end clean up code 

      return oldFunc.apply(this, arguments); 
     }; 
     return oldRender.apply(this, arguments); 
    }; 
})(); 

Jeden z twórców Meteor podstawowych na forum Google Groups poinformował mnie (link), że są one ponownie pisać pakiet szablonów i będzie rozwiązać ten problem.