Um sub-workshop para preencher o FAQ (perguntas mais freqüentes). Vamos ajudar os camaradas! - página 14

Novo comentário
 
TheXpert:
E a coisa certa a fazer, imho, é sempre pedir ao terminal as informações mais atualizadas.

O estado das ordens (matriz) é consultado precisamente quando elas precisam ser tratadas.

Não estou argumentando que podemos passar sem isso, e não precisamos ter uma visão em massa de antemão. E imediatamente analisar o estado dos pedidos sob demanda após OrderSelect e filtrar os indesejados por mágico, símbolo, etc.

Mas você argumenta que a matriz de bilhetes é uma UG. Justificar o motivo.

-------------

Taras sugeriu a opção "ultra" quando todas as informações sobre pedidos são escritas para array. Só posso concordar com isto na posição de que toda esta informação não é necessária. E na versão simplificada, na maioria das vezes, só são necessários bilhetes.

 
TheXpert:
Eu não o sugeriria. Na maioria das vezes, não é necessária uma variedade de bilhetes. E a coisa certa a fazer, imho, é sempre pedir ao terminal as informações mais atualizadas possíveis.
Em um array você obtém informações, vivendo condicionalmente 1 carrapato. De que mais informações "frescas" você precisa? Eu utilizo minha própria prática, quando tenho 2-4 contas em múltiplas moedas (quero dizer a demo) que não permitem "perturbar o servidor" por coisas desnecessárias.

E em geral, este é o seu e meu ponto de vista pessoal. E o usuário deve sempre ter o direito de escolher - cujos argumentos são mais sensatos. ;)

P.S. E eu só dei a MINHA resposta à pergunta colocada na FAQ. :)

 

OK, IMHO UG porque IMHO é correto ter as informações de pedidos mais atualizadas. E IMHO você pode fazer sem uma variedade de pedidos 95% do tempo.

Você quer - acrescente, eu só estava dando minha opinião.

 

Vamos colocar as coisas desta maneira:

- Em termos de conveniência e abstração de modelos, é melhor usar arrays.
- Para acelerar o trabalho - sem arrays.

A relevância da informação não tem nada a ver com ela. Em ambas as variantes - com ou sem arrays - a relevância é 100% fresca

 
sergeev:

-------------

Taras sugeriu a opção "ultra", onde todas as informações sobre o pedido são escritas para a matriz. Só posso concordar com isso na posição de que todas essas informações não são necessárias. E na variante simplificada, na maior parte das vezes, só são necessários bilhetes.

Alexey! estou longe de pensar que ao introduzir esta pergunta no FAQ (Obtendo uma série de bilhetes de "próprios" pedidos), você quis dizer sobre "a posição que toda esta informação não é necessária" - gosta de brincar por aí?!
Ou eu entendi mal alguma coisa?
 
TarasBY:
Alexey! estou longe de pensar que, ao introduzir esta pergunta no FAQ (Obter uma série de bilhetes de pedidos "próprios"), você quis dizer a "posição de que toda esta informação não é necessária" - gosta de brincar com...!
Ou eu entendi algo errado?

Por alguma razão, você incluiu todas as propriedades no conceito de "seu bilhete", além do bilhete.

Mas eu definitivamente fiz sua sugestão como uma extensão do recurso "apenas um bilhete".

Há uma necessidade freqüente disso também, especialmente ao analisar e comparar dados de ordem histórica.

 
sergeev:


Vamos colocar as coisas desta maneira:

- Em termos de conveniência e abstração de modelos, é melhor usar arrays.
- Para acelerar o trabalho - sem arrays.

A relevância da informação não tem nada a ver com ela. Em ambas as variantes - com ou sem arrays - a relevância é 100% fresca

Sobre a segunda ("para acelerar o trabalho - sem arrays"), eu não seria muito rápido para ser apressado.
A lógica simples sugere que o acesso extra ao servidor para "novas informações" é um tempo extra. E não pode competir a tempo com a obtenção das mesmas informações da matriz.
Há um especialista em velocidade de código - Victor (Vinin), sua opinião seria interessante!
 
TarasBY:
Sobre a segunda ("sem arrays para acelerar o trabalho"), eu não seria muito precipitado para ser categórico.
A lógica simples sugere que o acesso extra ao servidor para "novas informações" é um tempo extra. E não pode competir a tempo com a obtenção das mesmas informações da matriz.
Há um especialista em código de desempenho Victor (Vinin), sua opinião seria interessante!

Mais uma vez, quando se trabalha com propriedades de pedidos, não há nenhum servidor a ser contatado!

No comércio, a regra mais importante é a relevância (para não se tornar a UG sobre a qual TheXpert escreveu).
Portanto, se você se referir à lista de pedidos em cada função e criar um array novamente, isso definitivamente causará uma desaceleração. Isso causará o enchimento da matriz.

Assim, podemos economizar dinheiro na atualização da matriz e repetidas OrdeSelect (já de acordo com o bilhete).

Se você tem 1-2 ordens de trabalho, a matriz não é crítica, mas se você tem 50-100, ela já é essencial.

 
Direi mais: com base em meu conceito anterior de "Redução da carga do servidor" (eu o chamaria mais precisamente de "Otimização da Velocidade do Código"), recebo todos os preços em uma matriz separada (se eu precisar deles para várias ferramentas) no início do Start(). E se eu precisar fazer uma operação comercial, eu faço RefreshRates().

Não estou impondo esta abordagem a ninguém, apenas vejo a lógica por trás dela e uso este princípio em meus projetos.

P.S. Isto não é para iniciar uma disputa sobre este tópico, é simplesmente um argumento para o acima exposto.

 
sergeev:

Portanto, se você se referir à lista de pedidos em cada função e recriar a matriz novamente, isso certamente levará a uma desaceleração. Por causa do enchimento da matriz.

Eu disse isso? O conjunto de carrapatos é preenchido uma vez por carrapato, se a EA estiver trabalhando em cada carrapato. E então, em vez da amostragem habitual:
    for (int li_int = li_total - 1; li_int >= 0; li_int--)
    {
        if (OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }
Eu seleciono de
for (int li_TIC = 0; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

ou:
    for (int li_SMB = 0; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }
dependendo de como eu me sinto mais confortável com esta ou aquela função.
Devo concordar que a racionalidade desta abordagem é mais perceptível em sistemas com várias moedas, que são uma minoria.
1...789101112131415161718192021...24
Novo comentário