Прожорливость памяти ОЗУ MT5, проблемы с чтением/записью больших файлов - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
я когда-то сталкивался с такой проблемой. Делал много исправлений. Всего не помню - это было разовое задание,
но попробуйте задать здесь ArrayResize(arrRead_01,arrSize); 3 параметр
int reserve_size=0 // reserve size value (excess)
поэкспериментируйте.
Спасибо, но все тормоза и поглощение памяти, судя по экспериментам, приходятся на класс для чтения информации из файла. Может там можно что-то подправить?
Судя по скорости реаллокации памяти, массивы строк хранятся как массивы объектов, а не указателей на них, отсюда тормоза. Нужно, чтобы разработчики прояснили этот вопрос, от этого зависит решение.
Потом, парсер создаёт локальный массив ячеек из строки и затем копирует их в выделенную память - лишний костыль, причём существенный.
Если как массивы объектов - то, в зависимости от частоты и количества обновления ячеек в задаче, возможно, будет дешевле по времени не парсить файл при загрузке, а хранить ксв-файл как массив файловых строк и обновлять данные на лету (т.е. парсить строку при каждом обращении к ячейке). В любом случае, прасер нужно переписывать, он крайне неэффективен и не поддерживает закавыченные ячейки и годится только для импорта числовых таблиц.
Судя по скорости реаллокации памяти, массивы строк хранятся как массивы объектов, а не указателей на них, отсюда тормоза. Нужно, чтобы разработчики прояснили этот вопрос, от этого зависит решение.
Попробуем позвать разработчика, @Renat Fatkhullin - можете прояснить ситуацию?
Потом, парсер создаёт локальный массив ячеек из строки и затем копирует их в выделенную память - лишний костыль, причём существенный.
Как от него можно избавиться?
Если как массивы объектов - то, в зависимости от частоты и количества обновления ячеек в задаче, возможно, будет дешевле по времени не парсить файл при загрузке, а хранить ксв-файл как массив файловых строк и обновлять данные на лету (т.е. парсить строку при каждом обращении к ячейке). В любом случае, прасер нужно переписывать, он крайне неэффективен и не поддерживает закавыченные ячейки и годится только для импорта числовых таблиц.
"Массив файловых строк" - это что Вы имеете в виду? Если это просто речь о создании массива, куда будут записаны все строки, то на сколько я понимаю, у длины строки есть ограничения по количеству символов, нет?
Класс для чтения писался сотрудником MQ, я думал, там всё грамотно написано.
Парсер правильно читает текст, тут с Вами не соглашусь - скрипт ранее приложенный это подтверждает.
Попробуем позвать разработчика, @Renat Fatkhullin - можете прояснить ситуацию?
Как от него можно избавиться?
"Массив файловых строк" - это что Вы имеете в виду? Если это просто речь о создании массива, куда будут записаны все строки, то на сколько я понимаю, у длины строки есть ограничения по количеству символов, нет?
Класс для чтения писался сотрудником MQ, я думал, там всё грамотно написано.
Парсер правильно читает текст, тут с Вами не соглашусь - скрипт ранее приложенный это подтверждает.
Он правильно читает файлы, где нет закавыченных строк, внутри которых есть символ разделителя. Попробуйте прочитать им 60;""sample;string"". На выходе должно быть 2 ячейки: [60] и [sample;string]. А будет, видимо, 3 - [60] [""sample] [string""]. (ЗЫ кроме того, в ксв допускаются переносы закавыченных строк :) )
Я знаю, как я от этого бы избавился в си или плюсах - аллокировал бы сначала массив указателей на строки и заполнял бы его, парся строчку. В мкл нет указателей, я не врублюсь, как подойти к этой задаче. Надеюсь, Ренат сможет прояснить.
"Массив файловых строк" - это что Вы имеете в виду? Если это просто речь о создании массива, куда будут записаны все строки, то на сколько я понимаю, у длины строки есть ограничения по количеству символов, нет?
В смысле, прочитать файл построчно и хранить каждую исходную строку файла в массиве, не парся её. При обращении к строке по формату (row, column) брать строку row, парсить её на лету и отдавать значение column, попутно кэшируя результат парсинга.
Вот ещё возможное решение. При чтении файла делать предварительный разбор - сохранять для каждой строки массив двух целых значений: индекс символа, с которого начинается значение ячейки в строке, и длина этой подстроки.
Например:
строка в файле : 54;345;12;12345
индекс символа : 0 3 7 10
длина подстроки: 2 3 2 5
Он правильно читает файлы, где нет закавыченных строк, внутри которых есть символ разделителя. Попробуйте прочитать им 60;""sample;string"". На выходе должно быть 2 ячейки: [60] и [sample;string]. А будет, видимо, 3 - [60] [""sample] [string""]. (ЗЫ кроме того, в ксв допускаются переносы закавыченных строк :) )
А, ясно, не знал о таких тонкостях стандарта CSV. Спасибо, что просветили об особенностях!
Я знаю, как я от этого бы избавился в си или плюсах - аллокировал бы сначала массив указателей на строки и заполнял бы его, парся строчку. В мкл нет указателей, я не врублюсь, как подойти к этой задаче. Надеюсь, Ренат сможет прояснить.
Будем надеяться, что Ренат сможет внести ясность.
В смысле, прочитать файл построчно и хранить каждую исходную строку файла в массиве, не парся её. При обращении к строке по формату (row, column) брать строку row, парсить её на лету и отдавать значение column, попутно кэшируя результат парсинга.
Да, думаю это было бы оптимально по времени, даже кэш особо не нужен, наверное. Можете помочь и внести соответствующие правки в класс для реализации этого подхода?
Вот ещё возможное решение. При чтении файла делать предварительный разбор - сохранять для каждой строки массив двух целых значений: индекс символа, с которого начинается значение ячейки в строке, и длина этой подстроки.
Например:
строка в файле : 54;345;12;12345
индекс символа : 0 3 7 10
длина подстроки: 2 3 2 5
Ну да, я примерно о таком подходе выше сегодня писал - посчитать с начала что по чем, а потом уже заполнять массив. Но не представляю, как это можно реализовать :(
WriteArray / Read работают быстро, макс. размер доходил до 300 мб, все оч быстро происходит, оперативку не жрет
че там кода столько для чтения\записи то, в 4 строчки все делается
WriteArray / Read работают быстро, макс. размер доходил до 300 мб, все оч быстро происходит, оперативку не жрет
че там кода столько для чтения\записи то, в 4 строчки все делается