Форум OlegON > Программы и оборудование для автоматизации торговли > ЕГАИС в опте и рознице

Программа "Амадей Моцарт" для работы в ЕГАИС : ЕГАИС в опте и рознице

29.03.2024 3:49


01.07.2022 09:20
AndreyZh
 
Цитата:
FinSoft Андрей, извиняюсь, запустил из любопытства твою прогу от 2018 году, которая без пароля. У меня стойкое впечатление, что там эмулятор. Обработка нажатия клавиш прямо с заметно задержкой проходит по сравнению с обычным виндовым приложением. Far, к примеру, работает быстро, он вроде как консольный. Это из-за старой версии может?
Вячеслав! Как-то неудобно, т.к. здесь обсуждают Моцарта, а не Жукова... Так, что по замечаниям по моему инструменту велкам в https://olegon.ru/showthread.php?t=17546&page=6, а по возможностям моих систем: https://olegon.ru/forumdisplay.php?f=72... В частности читал и смеялся над Вашими попытками отделить обороты, доходы, возвраты по поставщикам и etc, когда меня изначально это не "гондурасило", т.к. учет ведется исключительно по партиям
01.07.2022 09:57
FinSoft
 
Цитата:
AndreyZh Вячеслав! Как-то неудобно, т.к. здесь обсуждают Моцарта, а не Жукова... Так, что по замечаниям по моему инструменту велкам в https://olegon.ru/showthread.php?t=17546&page=6, а по возможностям моих систем: https://olegon.ru/forumdisplay.php?f=72... В частности читал и смеялся над Вашими попытками отделить обороты, доходы, возвраты по поставщикам и etc, когда меня изначально это не "гондурасило", т.к. учет ведется исключительно по партиям
Ага, ответил туда. Сразу извинился, что не в той теме спросил, вопрос косвенно всплыл. Как у тебя ведется учет по партиям, я уже выучил. Там совсем другое, как сравнивать теплое с мягким.
01.07.2022 10:27
amadey
 
Цитата:
AndreyZh 64битным компилятором... Уже делал и использовал такое. Как "цимус" - снимаются абсолютно все ограничения на размеры таблиц (БД), длины имен и объектов, да и скорость возрастает в 2-3 раза при любых операциях...
Я в увеличение быстродействия не особо верю. Когда-то меня в универе учили проектировать микропроцессоры. То, что все переменные начинают в памяти занимать 16 байт, даже самые простые счетчики и булевы переменные, конечно раздувает до неразумного размер расходуемой памяти, однако в зависимости от операции скорости скорее падают чем растут. Они вырастут на переменных где действительно нужно сочетание высокой разрядности и точности чисел, но, как правило, нам нужны переменные, в которых нужно записать 1-2 цифры.... Количества это как правило до 100, пусть до 1000 , цены это как правило от 10 до 1000 рублей, и еси всегда для всех цифр использовать 64 разрядные 8 байтовые переменные, процессор хоть и кажется что за один тик выполняет какую-нибудь операцию умножения, однако внутри процессора микропрограмма все равно начинает двигать биты в переменной, а когда их много, то на это расходуется лишнее процессорное время - двигать в основном нули в этих 64 разрядах. На высокоточных и высокоразрядных данных скорость растет при переходе от 32 к 64 разрядности, а на низкоточных и низкоразрядных данных скорость только падает. помню как разработка калькулятора у меня был курсовой проект на простой логике к155ЛА3 2и-не. И писал микропрограмму умножения для управляющего автомата операционным автоматом. Чем больше разрядов тем тормознее эта микропрограмма работает.
01.07.2022 10:41
AndreyZh
 
Цитата:
amadey Я в увеличение быстродействия не особо верю
Изучая тему сборки проги под конкретную ОС до кучи проверял быстродействие... Согласен, что на математических операциях скорее всего получим деградацию скорости 64 разряда по отношению к 32/16 разрядам на дополнительных потерях по адресации, но меня "математика" мало интересовала, а волновала скорость работы с БД.

Сейчас актуальны 32 разрядная система умеет работать с 4Гб памяти (реально ОС оставляет 2.5Гб) + 1 Гб резерв под индексы и фактически требует (общий_размер_всех_таблиц * 3)... Была БД с общим объемом таблиц 2 Гб, т.е. в 32 разрядной ОС излишек БД свопировался на жесткий диск... и вот на этом примере и увидел преимущества 64 ОС и программы собранной под неё... Сейчас, по факту нет пользователей с такими БД.... Замечу - измерялось: примерно равное число операций, размер БД, УС Лэнд: 320Мб, 1С платформы 2.0: 5.8Гб, 1С платформы 3.0 14 Гб
01.07.2022 10:53
FinSoft
 
Вообще, Моцарт прав. 64 битные программы позволяют адресоваться к большему объему памяти, а скорость выполнения операций при этом снижается. Дальше уже зависит от приложения и характеристик железа. Кстати, чтобы снять ограничение с размера базы, не достаточно просто перекомпилить программу в 64 бита. Должен драйвер (библиотека, через которую работает прога с базой) поддерживать длинные указатели. Насколько я знаю, это не такой простой вопрос, требующий существенной модификации кода драйвера.
01.07.2022 12:17
amadey
 
Сейчас посмотрел размер моей базы данных главного склада, которая отработала с 1993 года по сей день, обслуживала 4 собственных магазина и кучу сторонних, в которой 2000 наименований товаров.... Общий объем базы данных 33 мегабайта. Я по экономичности обскакал всех. Но это моя собственная разработка базы данных, я делал ее максимально экономичной.
Думаю что в других системах такие раздутые базы от полного отсутствия гениальности их изобретателей. Думаю что там просто мусор на 99% хранится. И по быстродействию я думаю что я вне конкуренции. Одно дело перелопачивать 33 мегабайта другое дело 15 гигабайт.
01.07.2022 12:29
amadey
 
А причина этого - в бездумном использовании индексов везде где не попадя. Какой смысл в индексах на документе из 10 товаров?
У меня быстрейшую из не индексных сортировку и поиск я сделал по рекурсивному алгоритму. Мгновенная работа на документах наиболее вероятного небольшого размера, очень быстрая работа на документах до 10 000 записей... А уж на критичных справочниках свыше этого размера я скрипя зубами добавил один самый критичный индекс - по идентификатору товара. И придумал что в группах справочника товаров они всегда по алфавиту вставляются - что дало возможность сделать не индексный мгновенный бинарный поиск. Работать с товарами по алфавиту всегда удобно, быстродействие самое максимальное, и никаких раздуваний базы индексами. Никто не сравнится со мной в гениальности технологий, в экономичности, в быстродействии. Можно поливать грязью, а гениальность мою не превзойти. И это не какая не теория бреда. Это реальная программа, установленная в 1500 предприятий с 1993 года по сей день. Это проверено практикой.
01.07.2022 12:32
amadey
 
А вы, изобретатели учетных программ, может и хотели бы лучше, как я, но вы - заложники чужих СУБД. А у меня с моей личной СУБД - полная свобода. Что хочу то и ворочу. И это (моя личная база данных) - мое очень большое преимущество.
01.07.2022 13:09
AndreyZh
 
Цитата:
amadey А вы, изобретатели учетных программ, может и хотели бы лучше, как я, но вы - заложники чужих СУБД. А у меня с моей личной СУБД - полная свобода. Что хочу то и ворочу. И это (моя личная база данных) - мое очень большое преимущество.
Действительно, а зачем человеку язык? Что-бы молоть чушь?

Извините, но за всю жизнь и до этого Вашего утверждения, не слышал о профессиональном тестировании Вашей СУБД Да и в списке миллиардеров не встречал разработчиков УС на уникальной СУБД собственной разработки... а Вы не предлагали её лохам в MS или Oracle?

Однако, если серьёзнее, в срезе сельмага... Как можно проверить Ваше утверждение о выдающейся производительности СУБД? Да и ещё, что-бы это было доказуемо для all?
01.07.2022 13:20
AndreyZh
 
Цитата:
FinSoft Вообще, Моцарт прав. 64 битные программы позволяют адресоваться к большему объему памяти, а скорость выполнения операций при этом снижается. Дальше уже зависит от приложения и характеристик железа. Кстати, чтобы снять ограничение с размера базы, не достаточно просто перекомпилить программу в 64 бита. Должен драйвер (библиотека, через которую работает прога с базой) поддерживать длинные указатели. Насколько я знаю, это не такой простой вопрос, требующий существенной модификации кода драйвера.
Одна мысль, но сколько в ней неоднозначных утверждений!!! Я в восторге! Попробую написать, но не буду доказывать, т.к. требует много времени... Однако эти исследования проводились в 2010-2011 годах.

1. Возможно скорость в рамках Ram, как писал выше у 32 разрядного приложения выше, но я писал о ситуации выхода из пределов памяти;
2. Приложения на [x]Harbour имеют единый исходный код, компилируются в один код для приложений любой разрядности, т.е. мне ничего не нужно "модифицировать":
3. На этапе сборки exe файла выбранным компилятором C++ происходит подключение библиотек от C++, адаптированных под соответствующую ОС и/или разрядность... В результате моё прикладное приложение сразу начинает удовлетворять технологиям, ограничениям среды компиляции C++... При обсуждениях, например убирается ограничение на размер файла 4Гб или точность расчетов.
Часовой пояс GMT +3, время: 03:49.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.