OOP에 대한 도움말 - 페이지 8

새 코멘트
 
중재자에게 요청: 우리 말에서 분기를 정리하십시오.
 
청소할 필요가 없습니다. 후손을 위해 남겨두십시오.
 
fxsaber # :

잘못된 비교 때문에 개체의 자동 삭제 시간은 고려되지 않습니다.

변경됨.

V3 이후의 123MB는 어디에서 왔는지 - 모르겠습니다.

문제는 벤치마크에서 각 기능이 몇 번 실행되는지입니다.

평균 시간, 실행 횟수 및 stddev의 출력이 필요합니다.
 
Vasiliy Sokolov # :

문제는 벤치마크에서 각 기능이 몇 번 실행되는지입니다.

정확히 한 번.

평균 시간, 실행 횟수 및 stddev의 출력이 필요합니다.

전투 고문에서는 지연 버스트가 중요합니다. 이론적인 실험을 많이 하지 않았기 때문에 그런 일은 하지 않았습니다.

 

Vasiliy Sokolov # :

아니, 맞아. 그리고 이것이 근본적인 요점입니다. 시간 비용이 매우 많이 드는 메인 스레드에서는 자동 삭제가 발생하지 않습니다.

불행히도 함수 내부와 외부를 측정하면 시간이 다릅니다. 내부가 더 빠릅니다. 저것들. 개체를 삭제하면 어떻게 든 영향을 미칩니다. 따라서 다른 스레드에 대한 버전은 약간 의심됩니다.

두 번째 순간. V2에 주목하세요. 개체 삭제가 없으며 직접 메모리 누수가 의도적으로 허용됩니다. 이 경우에도 개체 선택에 1.4초가 걸립니다. V1의 1.2 대 , 삭제에 시간이 전혀 낭비되지는 않지만.

나는 반대의 그림을 가지고 있다.

 

mql 프로그램을 실행하는 동안 수집기는 동일한 스레드 또는 다른 스레드에서 아무 것도 제거하지 않습니다.

수집기는 명목상 존재하지만 모듈이 종료될 때만 실행됩니다. 로그의 누출된 메모리에 대한 메시지는 수집기일 뿐입니다.

 
fxsaber # :

정확히 한 번.

이 경우 벤치마크는 관련이 없습니다. 적어도 나를 위해.
 
Vasiliy Sokolov # :
이 경우 벤치마크는 관련이 없습니다. 적어도 나를 위해.

내 구현이 아닙니다. 구식 방법으로 측정할 수 있습니다.

 
fxsaber # :

따라서 다른 스레드에 대한 버전은 약간 의심됩니다.

확인.
 
일반적으로 아무도 일종의 본격적인 GC에 대해 이야기하지 않습니다. 그런 것은 없지만 독특한 방식으로 작동하는 매우 단순화된 것이 있습니다.
123456789
새 코멘트