The problems stated in update #8 were all solved surprisingly fast
- Graph layout - solved (for now) with grandalf - a fun little module solving most of layouting problems with it's Sugiyama Layout.
There is a problem though - nodes of grandalf do not care about the order of output edges, but my node editor does care, so generated output edges may intersect. not a huge problem for now, will leave it for the future me. - Лэйаут графа нод - решено (на пока что) grandalf-ом - маленький лёгкий модуль, решающий все мои текущие проблемы своим лейаутом Сигуямы.
Единственная проблема - ноды в grandalf не имеют порядка рёбер, но ноды в моём графе имеют строго сортированные входы-выходы, так что в результате лейаута эджи могут пересекаться. - Basic resouce management - you can set cpu and ram requirements, that's the most basic, good for now, doesn't matter at all if you run it locally
- Базовый менеджмент ресурсов реализован - инвокации могут задавать требования к числу процессоров, к размеру памяти - заглушка на пока что, не важная вообще, если все воркеры запущены локально
- Copy-paste - now that was an underestimated beast.
Server-side node duplication is easy, but it's not quite copy-paste.
Client-side copy-paste requires the ability to serialize node snippet into sequence of commands for the server, and then execute those commands on paste action, as an async job in background of the client. - Копи-пейст оказался неожиданно нетривиальным.
На стороне сервера реализовать дупликацию нод - легко, но это не совсем копи-пейст
На стороне клиента - реализация требует некоторого формата сериализации графа в последовательность команд для сервера,
так же требуется возможность выполнять такие последовательности команд на стороне клиента в асинхронном режиме. - ctrl+z - well, that i forgot...
This requires implementing some kind of command log with reverse command saved to it. Not yet implemented - контрл+z - мда, пока что забыл...
Это требует реализации некоторого командного журнала с сохранёнными в нём инвертированными командами. Пока не реализовано.
Before going forward decided to start a new video project to extensively use taskflow in, also to compare it to TOPs
Вместо того, чтобы продолжать абстрактный девелопмент, я решил протестировать систему на реальном проекте, для чего начал подготавливать матеирал для нового видео. За одно можно сравнить юзер экспириенс работы таскфлоу и с ТОПом
It works surprisingly well so far.
Система работает вцелом на ура.
The major downside now is the inefficiency of UI network protocol and UI itself (the viewer) - displaying thousands of tasks grinds it to a choppy experience, and current network protocol sends full update on all selected tasks every second, which eats cpu time both on scheduler's side and on UI side.
Главная проблема на данный момент - неэффективность сетевого протокола для интерфейса пользователя, и самого интерфейса пользователя (программы вьюера) - Отображение тысяч тасков одновременно серьезно просаживает произовдительность интерфейса, плюс текущий сетевой протокол втупую шлёт полный апдейт по всем таскам запрашиваемой группы каждую секунду, что жрёт процессорное время и на стороне шедулера, и на стороне вьюера.
The solution for protocol is obvious - send incremental changes over time, and do full sync only once in the beginning. It just takes time and a bit of DB restructurizing to enable smth like "last change" column.
Решение проблемы с протоколом очевидное - не слать полный стейт, слать только изменения с определённого времени. Реализация требует некоторого времени и небольшой рестуктуризации базы данных, например для добавления поля "последнее изменение" во все табилцы.
The solution for for viewer's UI - not that obvious. I see some memory leaks in python's side of Qt which i have hard time doing anything about. Plus my overall inexperience in heavy 2d graphical applications probably prevent me from seeing a "proper" way. I'll keep researching this area for now.
Решение же для вьюера - не такое очевидное. Я так же наблюдаю некоторые меморилики, связанные, похоже, с Qt, на что я едва ли могу повлиять. Кроме того из-за отсутствия опыта разработки приложений с тяжёлой 2д графикой я скорее всего не вижу каких-то очевидных путей и подходов.
Second problem that popped up - when there are more workers (just 12 in my tests, all i can do for now with my hardware to keep it realistic) - there was a surprisingly high amount of disk writing operations (~80/s). this is really not much at all, but scaling up can get this into uncomfortable values. Which can be especially important for SSDs with limited write operation lifespan.
Вторая неожиданно обнаруженная проблема - это как только я поднял число рабочих до 12 (в моём случае это оптимальный максимум по двум машинам, на которых они запущены) - я неожиданно обнаружил постоянный поток команд записи на диск (порядка 80 в сек). Само по себе это совсем не много, но при значительном поднятии числа рабочих может вылиться и в значительное количество записей, что может быть особенно важно для ССД дисков с их ограниченным сроком службы по числу записей.
All because all temporary runtime information about workers and invocations was still saved into database, and though SQLite's WAL mode uses memory mapped .db-shm files - my system still desided to fsync them often. On one hand - this is good - any type of power surge, crash or whatever - and DB will remain perfectly intact. On another hand - this runtime information, like last worker's ping reply, invocation progress report etc - these i don't really care if they get lost during crash - the scheduler will restore them fast after restart, so just taking that out of DB brought down disk operations to average of ~10/s, with complete 0 when tasks are not moving around (like when tasks' invocations are being executed)
И всё это из-за того, что вся, даже временная, информация, сохранялась в базу данных. И хотя WAL режим в SQLite меморимапит .db-shm файл - всё равно эти файлы часто синхронизируются с диском. С одной стороны - хорошо - любая ошибка, любое отключение питания, и база данных останется в корректном рабочем состоянии. С другой стороны - эта временная информация, типа состояния рабочих, прогресс инвокаций, мне в базе данных совсем не нужна. Убрав их из базы - число записей на диск уменьшилось до средних 10 в сек, с нулём записей если таски не двигаются по графу (например выполняются/ожидают выполнения)
That was a fun deeper dive into sqlite
Но это было интересное погружение в устройство sqlite
Will continue to work on my own project to produce some more user experience.
Продолжаю работу над своим проектом, используя taskflow, собираю с себя фидбек.
