Появилась потребность экспорта тиков в текстовый формат для загрузки в Amibroker. Использовал версию гидры 4.0.22 Обнаружил такие проблемы и неточности.
- Солюшн не собирается из-за постбилда плагина Plaza. Не находит какой-то файл. Мне не надо. Отключил.
- Экспорт не возможен без загрузки данных в грид. Это косяк, потому что на большое количество строк грид памяти жрёт немеряно. Нет информации об окончании экспорта, кроме отвисания формы. Поправил. И то, и другое и зависание. Раз доступ мне не дали, берите файлы отсюда.
Comentários (36)
Entrar ou Criar conta, Faça login ou cadastre-se para deixar um comentário
вызывает волшебный метод
Видно, что несмотря на интерфейс IEnumerable, вывод производится не через yield return, а обычным списком в памяти. Т.е. возможные миллионы строк утрамбовываются в оперативную память. Не очень хорошее поведение для высоконагруженной системы. Данные всего за 2 недели по фьючерсу RI отъедают при этом памяти около 4Гб.
,который по идее должен обеспечивать потоковый вывод в файл с минимальными затратами памяти, съедает этой памяти ещё в 2 раза больше (около 5Гб), чем окунает мой компьютер в файл подкачки "по самые не хочу". 7) И это ещё не всё. После окончания экспорта и закрытия окна сделок память не очищается. Принудительная сборка мусора помогает слабо. Видимо где-то большие объёмы хранятся в статическом поле. Приходится для каждого экспорта перезапускать программу.
В результате экспортировал RIH2 гидрой в 6 приёмов за 1 час, закрыв все приложения, ибо при работе программы с файлом подкачки ничего другое не работает в принципе. После чего за 2 минуты загрузил полученные файлы в Amibroker с расходованием максимально около 100MB памяти. Как говорится, почувствуйте разницу.
Проблема известная и уже была исправлена в дев ветке (появился IMarketDataStorage.Read). Кроме экспорта Гидры, так как сами мы из Гидры ничего не экспортируем. Можем дать доступ с учетом того, что доделаете выгрузку данных в файл через новый итерационный способ (типа yield).
PS Если кому надо, шаблон выгрузки в формате, который нравится Амиброкеру:
Если методы используются где-то ещё, то всё равно надо будет тестировать. У провайдера SQLite есть один большой косяк: он очень не любит конкурентные запросы на запись: несколько запросов на чтение возможны и в параллельных потоках, а вот при наличии запроса на запись, запрос на чтение может отвалиться даже если запущен просто сразу после запроса на запись (транзакция не успевает отработать). Итерационный способ повышает риски такой ситуации. MSSQL в этом отношении работает намного стабильнее.
4.1 не выгружает данные, загруженные версией 4.0.22. Метод Load работает так, как будто данных в папке нет. На первый взгляд поведение в доступном коде не отличается.
http://stocksharp.com/posts/m/17173/
Куда пост делся про метод Read? :) Что-то изменилось?
Это где я писал про производительность? Был не прав. Мой косяк.
Метод Read работает. Но сути это в целом не меняет. Память как жралась, так и жрётся (может быть меньше на самую малость). Проблема скорее всего в методе вывода в файл. Профайлером памяти не мерял ещё. Свой код оттестирую, выложу - сами посмотрите.
Согласен. Я экспортирую все в ручную, если требуется. Но для универсальности решил взять StringTemplate. Может есть какие-то другие альтернативы?
Выложил.
Заодно поймал ошибку экспорта в эксель: слишком много строк для XLS (больше 65000). XLSX поддерживает гораздо больше строк. Но всё-равно проблему наверное стоит решать дроблением файлов.
Раньше использовался коммерческий компонент. Сейчас он не используется, а используется NPOI. Может быть попробовать новые версии http://code.google.com/p/npoi/ ? Вышла какая-то, правда в бета режиме.
не надо. я обновлял, полезли ворнинги. от npoi зависит другой компонент ещё
Выложил изменение: Ограничил количество данных, выгружаемых в XLS, как и количество данных отображаемых в списке. Если кому надо, делайте дробление / пейджинг. А так хоть работает стабильно.
Переделал для себя экспорт в текст через библиотеку SmartFormat. Память не жрёт. Работает в несколько раз быстрее. Нада?
https://github.com/scottrippey/SmartFormat/wiki Это? Давайте. Только можно ее под 4.0 перекомпилировать, чтобы не было предупреждений компилятора.
Порефакторил ваши изменения. С прогресс баром лучше было бы сделать, чтобы он опирался на даты. Новая дата - увеличили прогресс.
Поправил поведение экспорта для соответствия поведению ReadRange, исправил экспорт в эксель
Нет, это баг, поправлю.
По выгрузке данных:
Зачем, если можно не устраивать перекрестную зависимость и сделать код элегантнее?
В принципе можно хранилище добавить функцию определения кол-во записей (оно храниться в метаданных), и тогда можно обновлять прогресс бар, скажем, для каждой 100-ой сделки.
Делегат - это не перекрёстная зависимость, а всего-лишь обратный вызов (декларироваться он может и там же, где и Read). Если в вызове нет необходимости, такому параметру можно просто присваивать null в перегруженном методе.
var totalDates = to - from; var percPerDate = 100 / totalDates;
for from to { foreach (var trade in Read(curr)) { FormatToFile(trade); }
progress.Value += percPerDate; }
Только сейчас заметил, что это обычный цикл, но через LINQ. Не суть. Просто, считаю, стоит задуматься об более интерактивном интерфейсе получения данных, если это получение занимает ощутимое время.
Это плохой стиль, потому что такие делегаты нужны только для GUI. Смешивать данные и GUI не очень хорошее решение.
Если это баг, то придётся править выгрузку назад (и прогресс), потому что я её уже поправил. Строго говоря по английски to - означает до (не включая), а включая - thru
Вообще конечно круче было бы заменить SmartFormat (который подтормаживает из-за рефлексии) на кодогенерацию обычного string.Format по шаблону T4, но больно много работы.
Я уже залил фикс, но все равно мне кажется чтение диапазоном не совсем хорошая вещь для данного случая (написал выше).
А сколько по времени сейчас для РИ 1 день выгружается?
Если нет желания добавлять такую функциональность в ядро, как вариант, можно конечно опять сделать обёртку над коллекцией.
Всё это гипотетически, потому что конкретно мне нынешней функциональности экспорта пока достаточно.
Убрал pdb файл, залил release версию String.Format под .Net 4.0 pdb файлам не место в Reference
в продакшен системе ничего это в принципе не должно быть. к тому же String.Format - сторонняя библиотека.
если надо отлаживаться при девелопменте - используйте локальный pdb файл.