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
"Quando se fecha um ficheiro, os dados são automaticamente repostos em disco, pelo que não há necessidade de chamar FileFlush() antes de chamar FileClose()" - Sim, sim, estou a começar a ver do que é queSergeev estava a falar. Então, acontece que em vez de FileClose() pode chamar FileFlush() para garantir a gravação do último registo no ficheiro? E esta seria uma solução inteligente?
não em vez de, mas por necessidade.
Flush - reinicia os dados restantes, e NÃO fecha o ficheiro. É isto que pretende, certo?
Fechar - repõe o resto dos dados em disco e fecha.
não em vez de, mas por necessidade.
Flush - reinicia os dados restantes, e NÃO fecha o ficheiro. É isto que pretende, certo?
Fechar - descarrega os dados restantes para o disco e fecha.
Algo sobre a minimização do tempo usando FileFlush() não funciona muito bem:
2011.05.29 21:58:20 FlushSave (EURGBP,M1) FileFlush. GetTickCount() = 133766
2011.05.29 22:00:33 FlushSave (EURGBP,M1) FileClose. GetTickCount() = 133734
De facto, é necessário o mesmo tempo para que ambas as funções funcionem.
Como entendi, esta linha move a posição para o início do ficheiro sem compensação. Isto permite sobrescrever a informação existente (isto é, a data é actualizada, mas não se acumula no ficheiro).
Ao utilizar mover para o fim do ficheiro em vez de SEEK_SET, os dados acumular-se-iam no ficheiro.
Abre-se uma nova pega de ficheiro cada vez que se puxa o autoclismo. Para quê? E, a propósito, não se fecha.
A vantagem da função FileFlush é que não é necessário reabrir a pega.
1. Pelo que entendi, esta linha move a posição no ficheiro sem compensação. Isto permite que a informação existente seja substituída (ou seja, a data é actualizada mas não se acumula no ficheiro)
Assim, se usado em vez de SEEK_SET saltar para o fim do ficheiro, os dados serão acumulados no ficheiro.Abre-se uma nova pega de ficheiro cada vez que se puxa o autoclismo. Para quê? E, a propósito, não se fecha.
A vantagem da função FileFlush é que não é necessário reabrir a pega.
Fi-lo desta forma:
Resultado:
2011.05.29 23:14:31 FlushSave (EURGBP,M1) FileFlush. GetTickCount() = 13563
2011.05.29 23:14:32 FlushSave (EURGBP,M1) FileClose. GetTickCount() = 531
Trocou as linhas, de acordo com a documentação:
Mas não compreendo o objectivo de chamar FileFlush() antes de FileWrite().Fi-lo desta forma:
Resultado:
2011.05.29 23:14:31 FlushSave (EURGBP,M1) FileFlush. GetTickCount() = 13563
2011.05.29 23:14:32 FlushSave (EURGBP,M1) FileClose. GetTickCount() = 531
Troquei as linhas, de acordo com a documentação:
Mas o ponto de chamar FileFlush() antes de FileWrite() ainda tem de ser compreendido.Aqui está a variante:
O resultado é FileFlush. GetTickCount() = 26125
Aqui está a variante:
O resultado é FileClose. GetTickCount() = 3969Esta opção deu um resultado entre 47 e 110
1. Conclusão - A utilização de FileFlush num loop atrasa a execução em cerca de 260 vezes.
2. Um laço para 50.000 registos nesta variante tem o seguinte resultado - FileFlush. GetTickCount() = 1891.
3. Não consegui matar o terminal ao executar o ciclo de escrita de 50000 sem sair do ficheiro (fechei o terminal e "matei" o processo).
4. Consegui matar terminal com 100000 laço, e o ficheiro continha mais de 65536 registos (tanto espaço no Excel 2003).
Troquei as linhas de acordo com a documentação:
Onde diz isso na documentação?
Como se pode dar sentido a algo que não tem um? Devolver a ordem das cordas e verificá-la duas vezes. Aparentemente, a documentação não o exprimia correctamente.
Mas... Graças aos seus testes, o bug parece ter sido detectado - FileFlush parece consumir uma quantidade desmesurada de tempo quando não são feitas alterações.Interessante:
OMG! É onde se deduz que se trata de um pântano. É assim que afirmações como "OOP é mais rápido" ou "os indicadores são lentos, devemos mover todo o código para o Expert Advisor".
Perito, anote como utilizar correctamente esta função.
Hipoteticamente, sim:
Ou seja, é correcto comparar FileClose -- Pacote FileOpen com FileFlush.
Teoricamente, FileFlush deveria fazer parte de FileClose e não poderia ser mais lento do que o pacote.
Não vale a pena descarregar as alterações antes de elas aparecerem porque ainda não estão lá :)
Mas, apesar das conclusões selvagens, os testes são indicativos, pelo que aguardamos comentários dos criadores sobre o funcionamento da função quando não há alterações.