можно дальше умничать, если список отделов не предполагается к изменению, и он достаточно маленький, можно использовать тип данных Перечисления (enum) когда список значений определяется прямо в типе.
В этом случае если у Отдел нет больше полей, то таблицу даже создавать не придется, но данные по этому enum придется где то хранить в виде констант в исходниках приложения (так как вытаскивать данные из ddl запроса муторно)
Пример - первого файла нет, а ты продолжишь писать данные из второго, это нормальная для задачи ситуация?
Или места на диске для записи файла нет (не фатальная ошибка) а ты продолжаешь читать данные из файлов и долбить файловую систему в попытках записать, что самое обидное у тебя иногда будет получаться, превращая итоговый файл в кашу.
Или что делать если читаемый файл в процессе увеличился в размерах (в него что то дописали)?
Отслеживать проблемные случаи зачастую правильно логично и исключает проблемы в будущем
да возможно но в windows будут некоторые проблемы с правильной настройкой окружения, так как в visual studio все уже загружено и настроено как ожидается.
Можно поставить компилятор от майкрософт visual studio sdk, мало того он уже стоит у тебя вместе со студией, им можно пользоваться прямо из командной строки, многие системы сборки его обнаруживают и позволяют пользоваться.
Есть батник "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" который устанавливает переменные окружение для указанной архитектуры в параметрах, если добавить его в вызов своего батника, запускающего nmake или напрямую компилятор cl и линковщик link, и компилируй свои приложения сам, оперативки для этого нужно меньше гигабайта.
Например можно поставить gcc (mingw, к сожалению проект заброшен, там старая версия) или clang gcc (там самая новая из собранных под windows но это llvm, даже хз плюс это или минус) так же отдельно лучше поставить какой-нибудь инструмент по управлению сборкой (make, nmake, cmake,scons,automake...) и вот тут начинается веселье, все самое интересное пришло из мира linux и в windows портируется как получится... в общем ковыряйся, мир этот огромный и непонятный, разберешься и уже считай огромный плюс как девопса, там как усилия сейчас на настройку и понимание окружения зачастую больше чем усилия на собственно кодинг.
p.s. если поставишь linux, то все будет очень даже из коробки, удобно и красиво
есть проект cygwin, до сих пор поддерживается хорошо, ребята портировали всю подсистему linux в windows так что собрав приложение под cygwin оно будет думать что работает в linux но при этом работать нативно на windows (это не виртуализация), к сожалению бинарники cygwin несовместимы с visualstudio/mingw
p.p.s. крупнейшая и лучшая на мой счет альтернатива visual studio как среда для разработки на c+= - это соответствующая подсистема eclipse (это для java но развилась так что там есть подсистемы подо все популярные языки, типа php, python и т.п.), вроде требования у них ниже чем у нынешней студии (а когда то было наоборот), но ее настроить тот еще квест
Обработкой прокрутки (и даже рисовать но это уже не обязательно, можно сделать тонкий div со скроллером) придется заниматься самому, ловишь событие движения скрола, вычисляешь на сколько нужно сдвинуть окно, и в цикле просто меняешь text в ячейках (если dom меняться не будет, то все произойдет очень быстро).
Во первых, на экране должно быть только столько ячеек, сколько видно (немного подумать что делать при изменении размера, например догенерировать ячейки, а чтобы это не было заметно, рисовать их чуть больше чем видно,.. ) зачем тебе рисовать ячейки за экраном?
Во вторых, в css нужно прописать чтобы ячейки не меняли свой размер от содержимого (обрезай)
93 тысячи пискселов, при реальных размерах экрана в пару тысяч, это очень много! браузер на простое поддержание такой страницы (двойной экранный буфер) тратит очень много оперативной памяти, вне зависимости от того что на ней нарисовано.
Отличный пример, создавай не поэлементно dom, а блоками, набираешь в виде строки html - вставляешь (например построчно тег tr)
Еще момент, вместо рисования миллиона ячеек таблиц с данными, можно один раз отрендерить все, а затем менять их значения при скролинге. Заранее пропиши, чтобы размер ячеек не менялся от содержимого.
Операции, меняющие структуру dom (положение на странице, размер) самые медленные
p.s. ты говоришь у тебя еще сама страница лагает, что ты там такое сделал?
если прямо так надо, рисуй все сам на канвасе, это самое быстрое.
сочувствую, что либо делать в таких условиях сложно
есть совет, найти старую версию vusial studio (примерно 2014 года или меньше) и поставить windows 7, правда найти ее можно будет только на торентах, и совет, устанавливать с отключенным интернетом, так как устновщик начинает что то скачивать, не находит и полностью ломается.
у 'быть бомжом' есть неплохой бонус, поганяло писать правильно (оптимально), использовать простые (а значит сложные для изучения) инструменты и т.п. На длинной дистанции это полезно. Грубо говоря, на с++ консольные приложения без отладки можно писать тупо в текстовом редакторе, зато разберешься с инструментами сборки приложений, будешь понимать что такое компиляция, объектные файлы, библиотеки и т.п.
Saboteur, неправильно думать так про цели корпоративности
плюс соцсеть это тебе не страничку-лендинг запилить, очень сложный проект, поэтому если мыслишь категориями 'это для корпоративных приложений' то уровень сложности задачи - сравним.
что и следовало доказать! запускай установщик Visual Studio и выбирай 'починить'
p.s. у тебя 32-битная windows? чудно
дело в том что постепенно поддержку 32-битных приложений будут прекращать все, рано или поздно... может майкрософт уже?
потербителей данных мало, по факту даже многопользовательского доступа у топиккастера скорее всего нет, максимум многопользовательское чтение и то без пересечения по данным, а значит любое решение с ее поддержкой будет менее эффективно.
Нет скорее региональная специфика, факты понижения скорости наблюдал неоднократно но не регулярно, понижение скорости происходит при объемах в несколько (десятки) гигабайт в сутки, это приличный объем для частника, понижение скорости скорее ради 'приструнить оборзевшего клиента', если что у меня трафик высокий до моих впс-ок, регулярно выдающих с десяток гигабайт в сутки
докину сверху, переделваю сейчас у себя организацию хранения данных логов сделок с криптовалютных бирж (к сожалению данные дырявые, много пропусков из-за ошибок в коде):
* на дешевых впсках крутятся простенькие скрипты, складывающие в текстовые логи дампы событий (что возвращает websocket), файлы нарезаются по времени, пакуются gzip и забираются моим отдельным сервером (раньше он и хранил, жутко неудобно работать с разрозненными данными, плюс там json-ы с лишней информацией, не эффективно хранить, если что один бинанс может выдать в сутки 5-6 гигабайт gzip-ов)
* будет крутиться отдельный бакэнд который будет переводить в общий формат хранения как я описал собранные данные
* итоговые файлы хранятся на отдельном файловом сервере, btrfs, включенное сжатие
* дальнейшей обработкой занимаются остальные машины, подключая по сети файловый сервер и забирая нужные файлы.
сюда бы еще дублирование серверов сбора данных (дешевые впски не надежны, а надежные дороги), анализ и объединение собранных логов, мониторинг проблем (место кончилось, интернет отвалился, сдохли сервера сбора данных) и т.п.
У тебя должен быть бакэнд, который принимает(читает) данные quik, исторические данные (старее некого интервала, например час) складирует сериализованными массивами в файлы с именем и каталогом, содержащими информацию о бирже, валютной паре и времени (начало интервала, а точнее abs(t/interval)*interval - эта формула из любого времени выдаст файл, в котором даные о событии), а данные по текущему интервалу хранит в оперативной памяти.
Твои insert и update храни как есть в логе, а в файлы сериализуй уже в своем формате, два типа событий trade (time,price,amount,type) и update (time,price,amount,side) либо (time,{bids:[[price,amount],..],asks:[[price,amount],..]}) amount +- означает увеличение или уменьшение объема по цене, 0 означает удаление, смотри сам, второй вариант компактнее
Если нужна надежность то у тебя должен быть промежуточный слой, складывающий лог событий в файл (его можно продублировать на разных серверах), который читает и обрабатывает бакэнд (очередь FIFO), в случае остановки бакэнда он просто прочитает пропущенные данные из лога.
Этот бакэнд не обязательно должен возвращать данные, так как они локально доступны в файлах, пусть твои приложения запрашивают у бакэнда список имен файлов, которые нужно прочитать чтобы получить запрашиваемые данные, для файла который содержит текущую голову потока пусть возвращает не имя файла а url к бакэнду на получение его.
p.s. через какое то время ты придешь к тому что большую часть агрегации (пример - вычисление candlestick, вычисление индикаторов и т.п.) у тебя будет делать тоже бакэнд, ибо зачем гонять голову потока данных туда сюда
upd. еще советую собирать стакан (текущий список bids/asks) на указанный момент времени на бакэнде, храня собранный на начало периода или периодически, довычисляя его из лога update, это понадобится для тестирования стратегий, использующих стакан для анализа или хорошей визуализации ситуации с ликвидностью (тепловые карты рисовать).
p.p.s. базы данных делают все то же самое (пишут transaction log, можно организовать master-slave репликацию для надежности и т.п.), но потребуют на это на порядок больше ресурсов, особенно если у тебя сотни и тысячи событий в секунду
отлично, причина найдена, осталось перебрать версии драйверов
лучший их источник - драйверпаки (кстати запускать их необязательно, можно вручную найти, скачав полностью, они там в архивах с удобной структурой лежат по названиям производителя чипсета и версии)
p.s. точно обновления отключены? первые сутки другие после установки (слабая машина может неделями) windows качает и устанавливает драйвера, сильно нагружая машину, и хотя они обещают что мешать это не должно, какраз в таких вот легких притормаживаниях это и обнаруживается
в браузере с youtube на том же видео проблем не наблюдается?
может хостер виноват (россия, башенный принтер, неадекваты тянут руки к интернету и все ломают)?
В этом случае если у Отдел нет больше полей, то таблицу даже создавать не придется, но данные по этому enum придется где то хранить в виде констант в исходниках приложения (так как вытаскивать данные из ddl запроса муторно)