Хм, используйте бесплатное ПО, после внедрения докупайте платный функционал.
Но даже в плане если не занимаетесь закупками, своим закупантам покажите другой(ие) продукт(ы) из которых вас устроит функционал, даже если изначально оно все платное.
по мне, так я лучше тот же симплайт возьму, чем вот это вот поделие... Хотя..., ищите во всем плюсы, с такой средой разработки хоть выспаться можно прямо на работе
этим и занимаюсьСообщение от melky
с такой средой разработки хоть выспаться можно прямо на работе
В Firebird выигрыш за счет кеширования результатов компиляции окон и многопоточной компиляции (Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)).
Что касается ресурсоемкости, то тут дело в том, что при наличия кеша окна не загружаются в память вообще, на видео 2 и 3 там видно, что память не превышает 6Гб, а при первой компиляции пока кеш не создан, расход был выше.
Выигрыш с Postgree будет на всех проектах, хотя бы за счет того, что процедура чтения из него выполняется в 4 раза быстрее. Также при работе происходит выгрузка неиспользуемых элементов, что снижает расход памяти. Позже напишем на данном проекте какие будут результаты.
Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз. Но за счет кеширования повторные запуски в процессе работы занимают минуту вместо 10 как было на 1.2 (на ней у меня компиляция после открытия заняла 14 минут, из них 4 - загрузка элементов и 10 - собственно компиляция, память доходила до 16Гб https://www.screencast.com/t/IDa2HYVEkSh)
13 минут - это только первый раз после конвертации, пока не созданы кеши. В дальнейшем окна будет перекомпилироваться с подгрузкой из БД только при их изменении или зависимых библиотечных элементов.
5 минут - это первый раз после открытия. Обычно проект открывают и работают с ним, вот в ходе этой работы повторные запуски будут укладываться в минуту. В ходе проверки этого проекта были сделаны некоторые оптимизации, в 1.3.1 попадут также ориентировочно во вторник
На моем видео видно, что во время компиляции окон загрузка доходит до 50% при 16 потоках (i7 11800H). Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем.
Обращения об ошибках принимаются от всех пользователей, даже кто использует демо-версию или бесплатную
Вот сижу читаю так как в недалеком будущем что то да приобрету MS4D уже чуть было не купил под проект под 4000 тегов... но решил посмотреть конкурентов как говорится чтобы не было мучительно больно... мне интересно в компании нет Бета тестировщиков???? что так после релиза быстро заплатки применяются...как то нехорошо в части имиджа...
....Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем... а есть реальный пример данного подхода и насколько выигрыш в производительности... допустим планирую скаду второго уровня тогда каждую опрашиваемую скаду первого уровня сделать отдельным узлом???
И при выборе железа в виде отдельного компа может есть оптимальные рекомендации с учетом "прожорливости" при апгрейде и новых фитчах в будущем
( в финансах не ограничен не люблю тормознутые системы могу сломать нечаянно как я понял в 28 ядер смысла нет)
Последний раз редактировалось dreambelarus; 11.03.2023 в 11:35.
...Веселись юноша в юности своей...
Вы сейчас пытаетесь навязать то, что при каких-то определенных условиях, будь то повторная компиляция или кеширование элементов, редактор будет работать быстрее.
Я не знаю, как большинство пользователей пользуется и работает с Вашим редактором, но опишу свое видение, почему я вообще затрагиваю эту тему. У меня есть готовый проект, который работает уже не первый год. И в большинстве случаев мне требуется либо поменять что-то в настройках протокола (в связи с заменой оборудования), либо добавить какой-то новый объект дублированием другого и последующим исправлением. А после переоткрыть редактор, чтобы освободить ОЗУ, и экспортировать проект. То есть получаем случай из Вашего первого видео - ждем 6 минут. А Вам самому нравится ждать такое время?
Да, я уже слышал от Ваших коллег, что мой проект сделан не совсем правильно, но я не вижу в этом ничего плохого.Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз.
Во-первых, с учетом того, сколько у Вас раньше было ошибок, я решил делать проект как можно проще, простота и надежность.
Во-вторых, все объекты у меня чем-то отличаются, поэтому делать кучу экземпляров на каждый уникальный элемент я не вижу смысла. То, что это как-то ускоряет разработку проекта - сомнительный аргумент. С учетом однотипной иерархии объектов и однотипным именованием элементов, дублированием я сделаю все гораздо быстрее, чем буду выискивать те самые "кирпичики", из которых мне требуется построить объект. В третьей версии Вашего продукта у меня был проект, который мне достался в наследство. Там все объекты были свалены в одну кучу, было много лишних элементов и связей, но почему-то все работало достаточно шустро.
В-третьих, переделывать такой большой проект, работа которого меня полностью устраивает, я не вижу смысла. Мое мнение в этом вопросе останется прежним - это не проект какой-то особенный, что он так долго экспортируется и тормозит, это редактор проектов такой особенный, что попросту не тянет.
Несколько раз перечитал, но так и не понял. О какой минуте идет речь? При описанном выше сценарии моей работы будет также 5 минут.13 минут - это только первый раз после конвертации, пока не созданы кеши. В дальнейшем окна будет перекомпилироваться с подгрузкой из БД только при их изменении или зависимых библиотечных элементов.
5 минут - это первый раз после открытия. Обычно проект открывают и работают с ним, вот в ходе этой работы повторные запуски будут укладываться в минуту. В ходе проверки этого проекта были сделаны некоторые оптимизации, в 1.3.1 попадут также ориентировочно во вторник
Давайте не будем передергивать. Во-первых, до 50% загрузка доходила на короткий промежуток времени; большую часть времени Ваш процессор, так же, как и мой, находился в простое, нагрузка в среднем была 10-20%. Во-вторых, ни на одном из Ваших видео я так и не увидел нагрузку по ядрам. Почему-то я уверен, что там также будет загружено два ядра из восьми. В чем такая проблема реализовать использование всех ресурсов процессора и диска? При чем независимо от того, сколько там у меня узлов в проекте и какую операцию я делаю.На моем видео видно, что во время компиляции окон загрузка доходит до 50% при 16 потоках (i7 11800H). Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем.
Почему какой-то винрар при архивировании небольшого файла стабильно (без всяких скачков) грузит все ядра? Почему Ваш продукт так не может?
винрар.png
Последний раз редактировалось b_aleks; 11.03.2023 в 12:58.
На хх.ру висят вакансии тестировщиков. Может как раз и не хватает рук.
Узел - это реальное физическое устройство, в которое будет грузиться проект. Поэтому Ваш вопрос не совсем понятен)....Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем... а есть реальный пример данного подхода и насколько выигрыш в производительности... допустим планирую скаду второго уровня тогда каждую опрашиваемую скаду первого уровня сделать отдельным узлом???
Надо разделять требования к исполнительной системе и среде разработки. В исполнительной системе все задачи, драйвера и внутренние службы работают в отдельных потоках, кроме того можно на одном сервере запускать несколько экземпляров системы с разными проектами или частями проектов. Так что тут все ядра легко задействовать.
Для среды разработки важен объем памяти (32+ для больших проектов), SSD диск. Дополнительные ядра могут ускорить процесс компиляции, как описано выше. В обсуждаемом выше проекте 5тыс внешних тегов, но из-за того что никак не используется типизация, получилось очень большое кол-во отдельных программ и окон, которые приводили к долгой компиляции (также при распаковке дискретных сигналов число реальных получается больше, чем внешних).
Я кстати не заметил, чтобы и SSD особо нагружался. Те средние показатели, которые выдает MS4D, вполне потянет обычный HDD.
Так не ускоряют же, Вы сами не видите что ли? Почему Вы не можете прямо ответить на вопрос? Почему два ядра используются из восьми? Из-за "особенностей" моего проекта? Если только из-за этого, то это полнейший бред, как мне кажется.Дополнительные ядра могут ускорить процесс компиляции, как описано выше.
Ну так сделайте для таких проектов многоядерную компиляцию. Что это за двойные стандарты? Тут мы сделаем поддержку многоядерности, а вот если пользователь решил по-другому принципу сделать свой проект, то пусть он мучается. Так получается? Ну смешно же.В обсуждаемом выше проекте 5тыс внешних тегов, но из-за того что никак не используется типизация, получилось очень большое кол-во отдельных программ и окон, которые приводили к долгой компиляции (также при распаковке дискретных сигналов число реальных получается больше, чем внешних).
И сколько заплатили, если не секрет ?
Если с нуля брать по тем лицензиям, которые у меня сейчас, то там сильно дорого будет. Больше полмульта. У меня обновление было с третьей версии на четвертую, по сути небольшие деньги были, тысяч сто может. Плюс саппорт (надо же обновляться из-за косяков!) для четырех ключей еще может около сотни.
Ваши права
Ответить с цитированием