TheXpert : 나는 제안하지 않을 것이다. 대부분의 경우 일련의 티켓이 전혀 필요하지 않습니다. 그리고 가장 정확한 IMHO는 항상 단말기에 최신 정보를 요청하는 것입니다.
배열에서 1틱 동안 조건부로 존재하는 정보를 얻습니다. 어떤 "신선한" 정보가 더 필요합니까? 2-4명의 다중 통화 거래자(데모에 대해 이야기하고 있음)가 동시에 내 계정에서 작업할 수 있는 내 연습에서 진행합니다. 다시 한 번 "아무것도 없이 서버를 방해"하는 것은 허용되지 않습니다.
일반적으로 이것은 귀하의 개인 및 제 관점입니다. 그리고 사용자는 항상 더 합리적인 주장을 할 수 있는 선택권을 주어야 합니다. ;)
- 모델의 편의성과 추상화의 관점에서 - 배열을 사용하는 것이 좋습니다. - 작업 속도를 높이려면 - 배열 없이.
여기에 있는 정보 의 관련성 은 관련이 없습니다. 어레이 유무에 관계없이 두 옵션 모두 관련성이 100% 신선합니다.
두 번째 것("배열 없이 작업 속도 향상")에 관해서는 범주형으로 서두르지 않을 것입니다. 간단한 논리는 "신선한 정보"를 위해 서버에 추가 호출이 추가 시간임을 나타냅니다. 그리고 어레이에서 동일한 정보를 선택하는 것과 제 시간에 경쟁할 수 없습니다. 코드 속도에 대한 전문가인 Victor(Vinin)가 있으므로 그의 의견이 흥미로울 것입니다!
TarasBY : 두 번째("배열 없이 작업 속도 향상")에 관해서는 범주형으로 서두르지 않을 것입니다. 간단한 논리는 "신선한 정보"에 대한 서버에 대한 추가 호출이 추가 시간임을 나타냅니다. 그리고 어레이에서 동일한 정보를 선택하는 것과 제 시간에 경쟁할 수 없습니다. 코드 속도에 대한 전문가인 Victor(Vinin)가 있으므로 그의 의견이 흥미로울 것입니다!
더 말하겠습니다. 앞서 "서버의 부하를 줄입니다"라는 개념을 기반으로 합니다(더 정확하게는 "코드 속도 최적화"라고 정의합니다). 시작 부분에서 또한 모든 가격을 별도의 배열로 가져옵니다(필요한 경우 여러 도구에 걸쳐). 그리고 거래 작업 을 수행해야 하는 경우 RefreshRates()를 수행합니다.
나는 이 접근 방식을 누구에게도 강요하지 않습니다. 나는 단지 그 안에 합리적인 입자를 보고 이 원칙을 개발에 사용합니다.
그리고 가장 정확한 IMHO는 항상 단말기에 최신 정보를 요청하는 것입니다.
아무도 이 논문에 이의를 제기하지 않습니다. 주문 상태 (배열)는 작업이 필요할 때 정확히 요청됩니다.
어레이를 사전에 사용하지 않고 그것 없이는 할 수 있다고 주장하지 않습니다. 그리고 OrderSelect 후 수요가 있는 곳에서 즉시 주문 현황을 분석하고 매직, 기호 등으로 불필요한 것을 걸러냅니다.
그러나 당신은 티켓 배열이 UG라고 말합니다. 이유를 정당화하십시오.
--------------
Taras는 주문에 대한 모든 정보가 어레이에 기록될 때 "울트라" 옵션을 제안했습니다. 이 모든 정보가 필요하지 않다는 입장에서만 동의할 수 있습니다. 그리고 단순화된 버전에서는 대체로 티켓만 필요합니다.
나는 제안하지 않을 것이다. 대부분의 경우 일련의 티켓이 전혀 필요하지 않습니다. 그리고 가장 정확한 IMHO는 항상 단말기에 최신 정보를 요청하는 것입니다.
일반적으로 이것은 귀하의 개인 및 제 관점입니다. 그리고 사용자는 항상 더 합리적인 주장을 할 수 있는 선택권을 주어야 합니다. ;)
추신 그리고 방금 FAQ에 제기된 질문에 대한 답변을 드렸습니다. :)
좋아, IMHO UG, 왜냐하면 IMHO 는 주문에 대한 최신 정보를 갖는 것이 좋기 때문입니다. 그리고 IMHO 는 95%의 경우에 일련의 주문 없이 할 수 있습니다.
자유롭게 추가하십시오. 나는 단지 내 의견을 표현한 것입니다.
다음과 같이 생각해보자.
- 모델의 편의성과 추상화의 관점에서 - 배열을 사용하는 것이 좋습니다.
- 작업 속도를 높이려면 - 배열 없이.
여기에 있는 정보 의 관련성 은 관련이 없습니다. 어레이 유무에 관계없이 두 옵션 모두 관련성이 100% 신선합니다.
--------------
Taras는 주문에 대한 모든 정보가 어레이에 기록될 때 "울트라" 옵션을 제안했습니다. 이 모든 정보가 필요하지 않다는 입장에서만 동의할 수 있습니다. 그리고 단순화된 버전에서는 대체로 티켓만 필요합니다.
아니면 내가 뭔가를 잘못 이해 했습니까?
알렉세이! 나는 이 질문을 FAQ("귀하의" 주문에 대한 일련의 티켓 받기)에 입력함으로써 "이 모든 정보가 필요하지 않다는 입장"을 의미했다고 생각하는 것과는 거리가 멉니다.
아니면 내가 뭔가를 잘못 이해 했습니까?
당신은 어떤 이유로 티켓과 그 모든 속성 외에 "당신의 티켓"이라는 개념을 추가했습니다.
그러나 나는 당신의 제안을 "그냥 티켓"의 확장 가능성으로 소개했습니다.
특히 주문 에 대한 과거 데이터를 분석하고 비교할 때 종종 필요합니다.
다음과 같이 생각해보자.
- 모델의 편의성과 추상화의 관점에서 - 배열을 사용하는 것이 좋습니다.
- 작업 속도를 높이려면 - 배열 없이.
여기에 있는 정보 의 관련성 은 관련이 없습니다. 어레이 유무에 관계없이 두 옵션 모두 관련성이 100% 신선합니다.
간단한 논리는 "신선한 정보"를 위해 서버에 추가 호출이 추가 시간임을 나타냅니다. 그리고 어레이에서 동일한 정보를 선택하는 것과 제 시간에 경쟁할 수 없습니다.
코드 속도에 대한 전문가인 Victor(Vinin)가 있으므로 그의 의견이 흥미로울 것입니다!
두 번째("배열 없이 작업 속도 향상")에 관해서는 범주형으로 서두르지 않을 것입니다.
간단한 논리는 "신선한 정보"에 대한 서버에 대한 추가 호출이 추가 시간임을 나타냅니다. 그리고 어레이에서 동일한 정보를 선택하는 것과 제 시간에 경쟁할 수 없습니다.
코드 속도에 대한 전문가인 Victor(Vinin)가 있으므로 그의 의견이 흥미로울 것입니다!
주문 속성 으로 작업할 때 서버에 대한 호출이 없음을 다시 한 번 상기시켜 드리겠습니다!
거래에서 가장 중요한 규칙은 관련성입니다(Xpert가 쓴 UG로 바뀌지 않도록).
따라서 각 함수의 주문 목록을 참조하여 배열을 다시 생성하면 확실히 느려집니다. 어레이가 가득 찼기 때문입니다.
즉, 일반적으로 어레이 및 re-OrdeSelect(이미 티켓에 있음)를 업데이트할 때만 저장할 수 있습니다.
1-2개의 작업 주문이 있는 경우 어레이가 중요하지 않지만 50-100인 경우 이미 중요합니다.
나는 이 접근 방식을 누구에게도 강요하지 않습니다. 나는 단지 그 안에 합리적인 입자를 보고 이 원칙을 개발에 사용합니다.
추신: 이것은 이 주제에 대한 논쟁을 시작하려는 것이 아니라 위의 주장일 뿐입니다.
따라서 각 함수의 주문 목록을 참조하고 배열을 다시 생성하면 확실히 느려집니다. 어레이가 가득 찼기 때문입니다.
나는에서 샘플링하고있다
또는:
특정 기능에 대해 나에게 더 편리한 것에 따라.
이 접근 방식의 합리성은 소수에 속하는 다중 통화 시스템에서 더 두드러진다는 데 동의해야 합니다.