다중 통화는 리소스 집약적입니다. 계산 때문이 아니라 단순히 여러 쌍에 동시에 액세스해야 하기 때문입니다.
돌을 싣는 문제가 너무 견디기 힘들다면 적어도 계산 간격을 몇 초에서 몇 초로 줄이십시오.
그리고 5개의 기호 자체인 imho는 그것과 아무 관련이 없습니다. 왜냐하면 돌의 로딩에 거의 기여하지 않습니다(개발자는 시스템을 가능한 한 적게 로드하는 방식으로 데이터가 클라이언트에 전송된다고 썼습니다). 네 자리 숫자 로 DC에 연결하여 따옴표의 비트 깊이의 영향을 확인할 수 있습니다.
결정적인 순간에 이것은 이해할 수 있습니다.
예를 들어, 일부 NFP에서 터미널은 일반적으로 무언가를 하려는 시도에 응답하지 않을 수 있습니다. 나는 다른 "무역 흐름이 바쁘다"라는 속임수에 대해 이야기하는 것이 아닙니다.
결정적인 순간에 이것은 이해할 수 있습니다. 하지만 topikstarter의 말에 따르면 프로세서는 항상 바쁘다.
그 중 20-30개가 있으면 먼저 손이 비뚤어진다는 가설이 나옵니다. 이 모든 불명예를 1초에 한 번 정도 계산할 수 있고 Core i7 2600K의 성능으로는 충분하지 않습니다.
topikstarter의 무능력을 의심하기는 어렵지만.
예, 터미널의 최소 CPU 로드는 25-30%입니다.
위에 쓰여진 모든 것을 요약하자면, 프로세서 부하 문제로 고생하는 사람은 나뿐만이 아닙니다...
나는 이것이 5가지 징후로 인한 것이라는 이론을 고수하지만 ...
위에 쓰여진 모든 것을 요약하자면, 프로세서 부하 문제로 고생하는 사람은 나뿐만이 아닙니다...
processlasso를 설치하면 만족할 것입니다. 프로세서 로드를 원하는 대로 설정할 수 있습니다.
결정적인 순간에 이것은 이해할 수 있습니다. 하지만 topikstarter의 말에 따르면 프로세서는 항상 바쁘다.
그 중 20-30개가 있으면 먼저 손이 비뚤어진다는 가설이 나옵니다. 이 모든 불명예를 1초에 한 번 정도 계산할 수 있고 Core i7 2600K의 성능으로는 충분하지 않습니다.
topikstarter의 무능력을 의심하기는 어렵지만.
병렬로 터미널에서 16개의 쌍이 계산되고 최소 2개의 터미널이 동시에 작동합니다.
인텔 코어 2 프로세서
글쎄, 그렇다면 모든 것이 분명합니다. 더 이야기 할 것이 무엇입니까 ... 다중 통화에는 많은 리소스가 필요하며이 경우 20-30 %는 충분히 견딜 수 있습니다.
여기서 프로세서 교체는 도움이 되지 않습니다(MT4인 경우). 계산 자체와 빈도의 최적화만이 도움이 될 것입니다.
다중 통화는 리소스 집약적입니다. 계산 때문이 아니라 단순히 여러 쌍에 동시에 액세스해야 하기 때문입니다.
돌을 싣는 문제가 너무 견디기 힘들다면 적어도 계산 간격을 몇 초에서 몇 초로 줄이십시오.
그리고 5개의 기호 자체인 imho는 그것과 아무 관련이 없습니다. 왜냐하면 돌의 로딩에 거의 기여하지 않습니다(개발자는 시스템을 가능한 한 적게 로드하는 방식으로 데이터가 클라이언트에 전송된다고 썼습니다). 네 자리 숫자 로 DC에 연결하여 따옴표의 비트 깊이의 영향을 확인할 수 있습니다.