freepascal.ru

>>еще не разу не прфилировал свою программу?
Собственно аопрос и возник изза того что я стараюсь тестировать zcad на пределе его возможностей.

>>профилирование тебе откроет где процик упахивается, может за зря.
А ты каким профилировщиком для fpc пользуешся 3 раза в день?

>>Вытащи рефреш в отдельный поток. тем самым скорость отрисовки вообще не будет зависеть от скорости в главном потоке.
Вот этот вариант еще хуже. Приплетать многопоточность - просто чтобы было - нетуж, извиняйте.

Тему про "навигаторы" пока сворачиваю, т.к. она упирается в другую тему - привязки к примитивам чужих обезличеных данных

Не надо пользоваться 3 раза в день - хватит знать где в каких местах идет "проседание". Вдруг возможно что какой нибудь не нужный for-do делает значительную задержку в коде. Профилирование укажет на это.
Для производства продукта 24/7/365 - без теста на утечек памяти, без профилирования - невозможно.

А почему бы не отделить модель представление от данных? Зачем все мешать в кучу? легче будет рендеру, и независимость появится от ввода данных. А если посадить на разные потоки то fps вообще не теряются..
У меня так сделано, рендер сидит на своем потоке, а когда данные подготовлены они добавляются к рендеру. отсюда реакция на события могут мгновенными, они независимые.

olegy123 писал(а):А почему бы не отделить модель представление от данных?

Например, чтобы избежать дублирование кода. Да и сама возможность разделения на потоки/процессы далеко не бесплатная.

>>Не надо пользоваться 3 раза в день
Ну хотябы тот которым когдато пользовался. Это я к тому что хреново всё с профилированием fpc программ.

>>А почему бы не отделить модель представление от данных
В процессе. чтото уже отдельно, чтото еще нет. Но к потокам это не имеет никакого отношения.

>>У меня так сделано
Я прям завидую, куда не ткни - у всех всё сделано))

zub писал(а):Я прям завидую, куда не ткни - у всех всё сделано))

Скоро и у тебя все будет =)

http://wiki.lazarus.freepascal.org/Profiling

zub писал(а):В процессе. чтото уже отдельно, чтото еще нет. Но к потокам это не имеет никакого отношения.

Там изначально нужно планировать изоляционный подход к модулям программ. Какие то процессы должны идти независимо от других, соответственно данные не должны быть в куче.. А быть подготовленные для конвейера в другом процессе.

zub писал(а):Я прям завидую, куда не ткни - у всех всё сделано))

Так я сначало все сделал в одну кучу - понадобилось работать со скриптом Lua - рендеринг запустил через него.. и опа.. fps просели..
Вот придумал, что работа с данными в одном месте должно быть, а результат должен быть в другом.
Короче сделал типа MVC(«Модель-Представление-Контроллер»). И сразу ощутил силу. Теперь мне не нужно мерить где упала мощность, все сводится к написанию маленьких минимодулей(моделей). Этим модели могут иметь даже свой выделенный поток, коммуникацию, хоть с интернетом. к общей системе зависимости практически нет. Оно есть когда нужно закинуть данные в рендеринг-конвейер, или обновить.

>>ttp://wiki.lazarus.freepascal.org/Profiling
Спасибо конечно, ты прям КО))

>>Там изначально нужно планировать изоляционный подход к модулям программ.
Изначально у меня было всё очень плохо. Сейчас тоже хвастать особо нечем, но уже гораздо лучше.

>>Этим модели могут иметь даже...
На словах всё очень даже... На деле не всё так просто. Допустим есть у нас есть чтото "типа MVC":
"модель" - 10e6 отрезков и представления - 10 вивпортов в которых эти отрезки отрисованы и 100 деревьев в которых эти оттрезки хитро сгруппированы и представлены пользователю чтобы он мог быстро найти нужный.
нас интересует 999ый отрезок, он попал в 5 вивпортов и 50 деревьев, имеет там свое "представление"
потом бац и 999ый отрезок нужно удалить из модели. из представлений ты его как удалять будешь? обшаривать 10 вивпортов и 100 деревьев в поисках нужного представителя?

Я не понял что за "вивпортов"
если про Select,
то можно же паковать поиск.. про результат -> где ID содержит информацию об отрезке и к какой группе относится.. можно делать map(id,..)
ну для человека не критично скорость, он может подождать, пока функция найдет нужный отрезок и поступит реакция.. а вот глаза его ждать не будут.

Добавлено спустя 1 минуту 25 секунд:
Вообще фронтенд это и наука и искусство и даже психология.

zub писал(а):нас интересует 999ый отрезок, он попал в 5 вивпортов и 50 деревьев, имеет там свое "представление"
потом бац и 999ый отрезок нужно удалить из модели. из представлений ты его как удалять будешь? обшаривать 10 вивпортов и 100 деревьев в поисках нужного представителя?

Делайте подобие виртуальной базы данных, с привязками. В смысле, если в одной таблице удаляется хрень(типа отрезок) по такому-то ID, то и во всех остальных таблицах эта хрень ссылающаяся на этот ID - удаляется автоматом. Соответственно, для повышения скорости удаления хрени(ссылок на отрезок), у оригинала хрени (отрезка) должны храниться ссылки на все связанные хрени существующие в проекте, тогда пользуясь этими ссылками - удаление хрени будет занимать всего несколько итераций процессора. В смысле удаляться, вся эта хрень - будет очень быстро и практически мгновенно.

>>Я не понял что за "вивпортов"
>>если про Select,
Тут уже я незнаю что такое select)) вивпорт - область отображения этиих самых отрезков.

>>у оригинала хрени (отрезка) должны храниться ссылки на все связанные хрени существующие в проекте, тогда пользуясь этими ссылками
сейчас у меня примерно так и делается, только не все еще на такую "архитектуру" переведено

Надо понимать простую вещь. Что MVC - далеко не панацея от всех бед.

zub писал(а):Тут уже я незнаю что такое select)) вивпорт - область отображения этиих самых отрезков.

Select - это OpenGLовский поиск попадания в регион.
по упакованному ID можно определить что это было на этапе чтения числа..

>>это OpenGLовский поиск попадания в регион
не использую и не советую

а шо, есть быстрые методы ?

а шо, если в системе нет OpenGL то и не выбрить ничего?