Erros, bugs, perguntas - página 2780
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Passos a dar:
É impossível não dizer Obrigado por um trabalho como este! Esperemos que um dia consigamos algo semelhante em outros insectos.
Não chores, já passou muito tempo desde que respondi:
Infelizmente, o resultado acabou por ser não só zero, mas negativo.
Bem, porquê negativo...
Não o recebi da primeira vez, não o recebi da segunda vez, mas recebi da terceira vez.
Não posso evitá-lo se sou tão grosso. Não é culpa sua.
Por isso, não se ofenda, Sergei.
Tem alguma incompreensão dos termos assíncrono e síncrono.
Quando se diz que uma função é assíncrona, significa que será executada não no fio da execução actual, mas em algum outro fio.
Chamar uma função assíncrona como ChartSetInteger a partir do fio principal é rápido, uma vez que a execução propriamente dita ocorre num fio diferente.
Por outro lado, uma chamada de uma função síncrona ChartGetInteger exigirá a sincronização dos fios e isto pode exigir tempo adicional.
Os atrasos são especialmente notáveis quando o fio paralelo está constantemente a actualizar os dados da estrutura gráfica (por exemplo, quando o utilizador move a janela gráfica ou percorre o histórico).
Muito provavelmente, por simplicidade e fiabilidade, um único objecto de sincronização é utilizado para a sua estrutura de dados gráfica.
Pode tentar melhorar a velocidade de execução usando "segmentação de dados", mas por outro lado, agora pode deparar-se com bloqueios, ou dados subactualizados, ou abrandamentos noutras áreas mais críticas.
Em geral, é melhor não tocar em algo que já esteja a funcionar de forma estável.
Não. Os métodos Get são sincrónicos, mas podem ser agrupados e executados simultaneamente, pelo que a chamada ao método 1 Get ou 100 é quase idêntica.
Os métodos definidos são assíncronos, mas também podem ser agrupados para maior eficiência.
Por conseguinte, é sempre melhor agrupar 'Fazer chamadas em conjunto' e 'Fazer chamadas em conjunto' em vez de 'Fazer / fazer / fazer / fazer / fazer'.
As chamadas assíncronas são mais eficientes se o fio de chamada não estiver bloqueado enquanto a função está em funcionamento, mas perderá estes benefícios se misturar Get and Set.
Espero que isto ajude, apesar da tradução.
Pelo que entendi - Get is synchronous, uma vez que devolvem o resultado solicitado. Mas se tiver o conjunto assíncrono na fila, tem de sincronizar-se com eles.
Se houver apenas Get's na fila, não há atraso.
Obrigado a todos vós. Estou lentamente a começar a apanhar-lhe o jeito.
Agora o verdadeiro quadro de tais atrasos torna-se claro.
Como o entendo (corrijam-me, por favor, se estiver errado):
Quando o método Get é chamado a partir do fio principal, há um pedido para o próprio fio do gráfico, que corre paralelamente ao fio principal. Mas o fio principal é controlado directamente do fio principal pelos métodos Set e o fio principal já deve saber o estado actual do fio gráfico, mas simplesmente não sabe o estado actual do fio gráfico e não tem a certeza se os últimos comandos foram executados. É por isso que este pedido acontece, para garantir que todos os comandos anteriores tenham sido executados. Uma vez que o método Get é síncrono, ele espera até que seja recebida uma resposta do fio do gráfico paralelo. Esta é a razão dos atrasos.
Se eu não cometi um erro, ocorre uma pergunta:
Porque não pode o fio principal reportar ao fio que o seu comando é executado, para que o fio principal possa marcar o comando como executado e actualizar a sua tabela gráfica interna? Então o fio principal devolveria os dados da tabela sem fazer pedidos ao fio principal. Além disso, poderia passar uma bandeira dizendo que existem comandos que ainda não foram executados para o fio paralelo ou que todos os comandos foram executados para compreender o estado actual do gráfico. Não haverá quaisquer atrasos com este esquema.
Implementei aproximadamente um mecanismo semelhante na classe iCanvas.
Aqui está um indicador, demonstrando este mecanismo, onde existe uma função incrivelmente lenta ChartXYToTimePrice para associar coordenadas pixel com o tempo e preço do gráfico e criar o seu análogo, a função XYToTimePrice, que actualiza as suas variáveis estáticas internas no evento CHARTEVENT_CHART_CHANGE e calcula os parâmetros solicitados com base nos dados deste gráfico estático de parâmetros do gráfico.
Obrigado a todos vós. Estou lentamente a começar a apanhar-lhe o jeito.
...Isto é verdade. E, como disse Renat, o sistema de cache precisa de ser implementado no lado do mql. Talvez pudesse ser implementado do lado da plataforma, mas isso comprometeria a realização da arquitectura multi-tarefa mais produtiva possível.
Estou a ver.
Tanto melhor para aqueles que compreendem como implementar este sistema de cache, e pior para aqueles que não compreendem.
Tentarei usar uma analogia, se não funcionar dessa forma, que assim seja.
É tudo muito exagerado e não é verdade, mas mesmo assim.
Há o cliente, que determina e traz as tintas ao artista, e há o artista, que usa as tintas que traz e pinta com elas na tela.
Depois de trazer as tintas, é livre de se dedicar ao seu negócio: trabalho, casa, escola, .....
Também pode visitar o pintor em qualquer altura e inspeccionar o resultado.
No entanto, se vier para uma inspecção e o artista estiver a pintar, terá de esperar que o artista termine o seu trabalho.
A melhor forma de interacção é trazer ao pintor todas as tintas de que ele necessita, ordenar-lhe que pinte e depois tratar dos seus assuntos.
No final, se necessário, pode visitar o pintor para inspecções, tantas vezes quantas as necessárias para aceder às telas.
A forma mais sub-óptima de interagir é trazer ao pintor uma tinta de cada vez e depois exigir o resultado imediatamente, esperando que o pintor complete o seu trabalho de cada vez.
Qual é o problema em 2485 em comparação com a construção de 2009:
Artista aproximou-se de si, o tempo de viagem para a inspecção começou a gastar menos, o que é uma vantagem.
No entanto, o artista começou a dedicar muito tempo ao trabalho "a tempo parcial" ao lado.
Ele costumava aceitar "trabalhos a tempo parcial" com a mesma frequência, mas agora tem de esperar demasiado tempo para que o artista complete o trabalho.
Estou a ver.
Tanto melhor para aqueles que compreendem como implementar este sistema de cache, e pior para aqueles que não compreendem.
A melhor maneira de interagir é trazer ao pintor todas as tintas de que necessita, ordenar-lhe que pinte, e depois tratar dos seus assuntos.
No final, se necessário, poderá visitar o pintor para uma inspecção quantas vezes quiser - terá livre acesso à tela.
Na minha opinião, a melhor maneira é concordar com o artista que, assim que terminar um quadro, indicará no seu site uma obra particular concluída que está disponível para visualização e também concordar que indicará o seu estado actual - se está a fazer trabalho a tempo parcial ou gratuito.
Então saberá que quadro está pronto e qual não está sem visitar o artista e se o artista estiver ocupado ou livre neste momento, poderá enviar-lhe o próximo trabalho. E não haverá necessidade de viajar em vão com uma inspecção. Poupará tempo e nervosismo tanto para o cliente como para o artista.
1) Na minha mente, a melhor maneira é concordar com o artista,
2) assim que ele terminar alguma pintura regular,
3) então ele apontou imediatamente para um trabalho específico feito no seu site, que está disponível para visualização pelo cliente,
4) bem como concordar em especificar no site o seu estado actual - está ocupado com a luz da lua ou livre.
5) Então o cliente saberá .... Se o artista estiver actualmente ocupado ou livre e puder enviar-lhe o próximo trabalho.
6) E não haverá necessidade de viajar em vão com a inspecção. Poupará tempo e nervosismo tanto para o cliente como para o artista.
1) O artista não conhece os seus planos e você também não conhece o futuro...
2) Não há pinturas, há uma tela sobre a qual vai toda a manipulação e "tinkering".
3) Introduzir processos não relacionados com o material de origem numa analogia não é compreender o que é uma analogia e para que serve.
4) Um pintor não conhece o futuro e se precisar de vir para uma inspecção, o seu estatuto pode mudar uma centena de vezes durante a viagem.
5) Pode trazer tinta em qualquer altura, leva sempre o mesmo tempo, independentemente do estatuto do artista ou do seu emprego.
6) Uma vez mais não compreender a essência do que é uma analogia e para que serve...