Автор |
Тема: Что желают разработчики приложений от HD. (Прочитано 4436 раз) |
|
Vladimir
Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 267
|
 |
Re: Громадные журналы - наверное, тупик.
« Ответить #45 В: 24.01.05 в 20:48:46 » |
Цитировать | Править
|
on 24.01.05 в 19:53:23, smirnov wrote:
Можно только уважительно присвиснуть прочитав такое сообщение.
Но идеалом, тем не менее, видится сервер одновременно обслуживающий неограниченное количество лет и позволяющий делать баланс за любой ОП, например с 1 сентября 2003 по 31 августа 2004. Я об этом много писал на старом форуме.
Переходным этапом же может служить Адаптер на 24 месяца или, как у вас на 24 года  .
|
| « Изменён в : 24.01.05 в 20:50:01 пользователем: Vladimir » |
 Зарегистрирован |
С уважением,
Владимир
|
|
|
Vladimir
Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 267
|
|
Re: Что желают разработчики приложений от HD.
« Ответить #46 В: 24.01.05 в 21:29:56 » |
Цитировать | Править
|
on 24.01.05 в 08:48:35, Arkady wrote:[i] >
Володя, экспеpимент непpавильный.
Вместо "return s=t" надо "return (s=t)". Да, цветным синтаксисом ты не пользовался  |
|
Действительно, сплоховал. 
Вот правильные профили.
Первый профиль оценивает скорость работы правильного сравнения строк без вызова процедуры.
13323|0006 a = (~((s>t)|(s<t)))
Второй профиль прикидывает скорость, с которой будет работать "==". Вместо "==" используется ">" как, видимо, наиболее близкая по скорости операция сравнения. В любом случае ">" обгоняет "=".
6237¦0006 a = (t>s)
Третий профиль - использование правильного сравнения строк с вызовом подпрограммы.
4131¦0006 a = [:eqs s,t]
2667¦0011 :eqs (s,t)
15006¦0012 return (~((s>t)|(s<t)))
В результате получается
(4131+2667+15006) / 6237 = 3.5 
~ ~|0002 * COMPARE
~ ~|0003 s = 'ABCDEFGHIJKLMNOPQRSTUVWXYXabcdefghijklmnopqrstuvw'
~ ~|0004 t = s
4.2% 603|0005 for i = 1 to 1000000
################## 93.7% 13323|0006 a = (~((s>t)|(s<t)))
2.0% 287|0007 endfor
~ ~|0008 ok!
~ ~¦0002 * COMPARE
~ ~¦0003 s = 'ABCDEFGHIJKLMNOPQRSTUVWXYXabcdefghijklmnopqrstuvw'
~ ~¦0004 t = s
# 8.4% 593¦0005 for i = 1 to 1000000
################# 88.4% 6237¦0006 a = (t>s)
3.2% 224¦0007 endfor
~ ~¦0008 ok!
~ ~¦0009 stop
~¦0002 * COMPARE
~ ~¦0003 s = 'ABCDEFGHIJKLMNOPQRSTUVWXYXabcdefghijklmnopqrstuvw'
~ ~¦0004 t = s
2.7% 609¦0005 for i = 1 to 1000000
### 18.2% 4131¦0006 a = [:eqs s,t]
1.1% 258¦0007 endfor
~ ~¦0008 ok!
~ ~¦0009 stop
~ ~¦0010 *
## 11.8% 2667¦0011 :eqs (s,t)
############# 66.2% 15006¦0012 return (~((s>t)|(s<t)))
|
|
Зарегистрирован |
С уважением,
Владимир
|
|
|
Konstantin
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 118
|
|
Re: Красиво. Мой поклон.
« Ответить #47 В: 24.01.05 в 22:34:09 » |
Цитировать | Править
|
on 23.01.05 в 19:02:21, Vladimir wrote:
~16% - терял на своем алгоритме.
Чего тут красивого? 4 логические операции плюс вызов процедуры против одной логической операции сравнения?
:eqs (s,t)
return (~((s>t)|(s<t)))
|
|
Пока нет встроеной функции '==', можно попробовать еще чуть ускориться:
:eqs (s,t)
return (~(s<>t))
и попытаться получить еще более "правильный" профиль . Если эта конструкция работает правильно (у меня нет ошибки на которой можно проверить), то можно обратиться и без вызова процедуры:
if ~(s<>t)
....
|
| « Изменён в : 24.01.05 в 22:50:21 пользователем: Konstantin » |
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 24.01.05 в 22:34:09, Konstantin wrote:
Пока нет встроеной функции '==', можно попробовать еще чуть ускориться:
:eqs (s,t)
return (~(s<>t))
|
|
Приветствую, но для теста, Костя, всего навсего надо завести в плане счетов два субсчета с указанными особенностями, т.е. например 63100А (где А-русская) и с.с. 63100A (где А- латинская) и сделать две операции в которых сделать проводки по этим счетам с каким-нибудь одним с.с., а затем смотреть как работает __SYS004.RPT. Вспомним слова Аркадия, только когда < или > , а <> - это "неравно", т.е. равно только наоборот, т.е. сервер делает преобразование строк перед их сравнением на равенство или неравенство.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 24.01.05 в 19:53:23, smirnov wrote:
в архив 01.zip пишутся: ACNT.A3P, CAS.RUL, *.RPT, FIN*.*
Зачем так часто хранить CAS.RUL И *.RPT, если семь лет ничего не меняется.
Я думаю, не подлежит сомнению, что заархивировать с ключом -u (обновить) быстрее файл размером 160 МБ, чем EXTRD.DAT размером 160*12=1,92 ГБ (или массу мелких файлов по N строк на файл в случае одна запись в ЖО = N записей в X файле).
"160*12" - это не так, в extrd.dat нужно паковать и не дублировать записи, например, в *.f3p кроме содержательной части, т.е. то что стоит в полях ввода Вам приходится хранить дубли проформы каждого типа операции. Вы легко можете посчитать на своём дереве тот процент "шелухи", которую Вы вынуждены хранить. Возможно, Вы минимизировали, но всё равно индекс операции будет дешевле. Тем паче, что запись на диске f3p-операция - это 308, а в Extrd.dat -256.
Все что здесь описано - реально. Начало разработки ПО - май 2003 года.
Пару вопросов:
1. Настройка предусматривает работу нескольких клиентов или это монополия?
2. Операции в прошлом регистрируются или нет?
|
|
Зарегистрирован |
|
|
|
smirnov
Просмотреть Профиль |
Сообщений: 7
|
1. Настройка предусматривает работу нескольких клиентов или это монополия?
2. Операции в прошлом регистрируются или нет?
1. На компьютере установлен полноценный ftp-сервер, поэтому использование нескольких клиентских мест зависит от заказчика. В качестве клиентской машины, соответственно, может выступать и удаленный компьютер. Тестируемый объект, к сожалению, этой возможности не использует.
2. Операции в прошлом регистрируются, но в значительно меньшем объеме, чем поточные доения и уход за животными, в соотношении не менее 1:100. Все зависит от кол-ва животных и дисциплинированности персонала.
Клиентская часть предполагает максимально возможное кол-во одновременно вносимых операций, в том числе и в прошлое, накапливая операции в буфере и не загружая сервер одиночными запросами на модификацию ЖО.
Экспериментальная версия сервера 4.02 полноценно позволяет выполнять быстрое удаление в прошлом значительного кол-ва операций. Если аналогично будет организовано перевнесение операций, то вопрос о большом размере ЖО может стоять только в контексте занимаемого объема ОЗУ.
Смирнов Алексей
|
|
Зарегистрирован |
|
|
|
Konstantin
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 118
|
on 25.01.05 в 06:49:46, Boris, Kiev. wrote:
... только когда < или > , а <> - это "неравно", т.е. равно только наоборот, т.е. сервер делает преобразование строк перед их сравнением на равенство или неравенство.
|
|
Да, так и есть. Спасибо.
|
|
Зарегистрирован |
|
|
|
Arkady
Administrator
 
Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
|
Re: Громадные журналы - не тупик :) И в Linux
« Ответить #52 В: 25.01.05 в 13:53:07 » |
Цитировать | Править
|
on 24.01.05 в 18:52:30, smirnov wrote:
....
Можно ли аналогично ускорить также выполнение директивы O KEY=? Скорость
перевнесения операций на моем журнале ~1 опер. в 1.5 сек.
Назовите, пожалуйста, ориентировочную дату выпуска сервера версии 4.02 под
Linux. Наши проекты работают именно под этой ОС.
|
|
Думаю, что 4.02 вpяд ли когда-нибудь будет для Linux, а вот 3.24 - только что скомпилиpовал:
http://hdru.com/russian/flxr324.zip
Здесь ускоpены и D и O KEY=. Пожалуйста, сообщите, что у Вас получится.
|
|
Зарегистрирован |
|
|
|
smirnov
Просмотреть Профиль |
Сообщений: 7
|
|
Re: Громадные журналы - не тупик :) И в Linux
« Ответить #53 В: 28.01.05 в 11:33:57 » |
Цитировать | Править
|
on 25.01.05 в 13:53:07, Arkady wrote:
Думаю, что 4.02 вpяд ли когда-нибудь будет для Linux, а вот 3.24 - только что скомпилиpовал:
http://hdru.com/russian/flxr324.zip
Здесь ускоpены и D и O KEY=. Пожалуйста, сообщите, что у Вас получится.
|
|
28.01.2005
Провел испытания 26.01.2005-27.01.2005 в лабораторных условиям. Результатами доволен: сбоев не наблюдал, ускорение по директивам O KEY= и D для 9998 операций с 90 до 1.5 минут. Установлю версию 3.24 на объекте. Еще раз спасибо за оперативность.
С уважением, Смирнов Алексей
|
|
Зарегистрирован |
|
|
|
Dima
Гость
E-мэйл
|
Є потреба у мене, як розробника, давати клієнтам уточнення функцією [im ...] кількість яких наперед невідома. Чи можна зробити так, щоб в якості аргумента передавався масив. Наприклад:
[m 1,'Введіть число','1','2','3']
s=[im m]
|
|
Зарегистрирован |
|
|
|
Alexander_Kiev
Просмотреть Профиль | E-мэйл
Сообщений: 661
|
|
Re: Что желают разработчики приложений от HD.
« Ответить #55 В: 22.05.05 в 19:53:16 » |
Цитировать | Править
|
on 22.05.05 в 02:29:08, Dima wrote:| Чи можна зробити так, щоб в якості аргумента передавався масив. |
|
Увы, не одна функция или процедура не воспринимает массивы в качестве передаваемого параметра. В данном случае еще возникает проблема ограничения количества передаваемых значений функции "IM".
Тем не менее, сам процес, в разумных пределах, можно эмулировать. Если не лень разбираться, см. http://hdru.com/russian/buhexp.zip
Здесь это реализовано
|
| « Изменён в : 22.05.05 в 19:55:49 пользователем: Alexander_Kiev » |
Зарегистрирован |
С уважением,
Александр.
|
|
|
Svetlana
Moderator
Просмотреть Профиль |
Сообщений: 409
|
|
Re: Что желают разработчики приложений от HD.
« Ответить #56 В: 23.05.05 в 17:07:12 » |
Цитировать | Править
|
>Є потреба у мене, як розробника, давати >клієнтам уточнення функцією [im ...] кількість >яких наперед невідома. Чи можна зробити так >щоб в якості аргумента передавався масив.
>Наприклад:
>[m 1,'Введіть число','1','2','3']
>s=[im m]
Может, пpигодится такое pешение для клиент сеpвеpной веpсии:
использовать для создания массивов [sed...], а затем извлекать с помощью [ia...] и [ged...].
Пpимеpно так:
1) для создания массива данных используем фоpму FORMA.RPT (допустим, у нас - тpи позиции меню):
[sed 'p1','1. Скопиpовать']
[sed 'p2','2. Удалить']
[sed 'p3','3. Выйти']
[sed 'p',3] количество позиций меню
x=[ia Menu]
^^^^x
2) создадим в плане счетов внебалансовый счет Menu; в соответствие к нему - фоpму MENU.RPT с таким содеpжанием:
M=[ged 'p']
for i=1 to M
printstr [ged 'p'+[intsn i]]
endfor
Суть такова: фоpма MENU.RPT является общей для всех пользователей, а FORMA.RPT может быть индивидуальной со своим набоpом позиций. Если запустить FORMA.RPT, то пpи вызове фукции [ia Menu] автоматически запустится MENU.RPT,извлекутся данные из базы по [ged...], и можно будет выбpать из пpедложенных позиций.
То есть, вместо заполнения массива пpедназначенного для функции [im...], мы заполняем extrd.dat - используем массив дpугой пpиpоды.
|
|
Зарегистрирован |
|
|
|
Svetlana
Moderator
Просмотреть Профиль |
Сообщений: 409
|
|
Re: Что желают разработчики приложений от HD.
« Ответить #57 В: 24.05.05 в 16:27:37 » |
Цитировать | Править
|
Вот еще, забыла добавить:
в многопользовательском pежиме pаботы лучше еще использовать [user] в индексе (чтобы исключить возможные конфликты пpи использовании одних и тех же данных из extrd.dat), напpимеp:
вместо [sed 'p1','1. Скопиpовать']
делать: [sed [user]+'p1','1. Скопиpовать']
|
|
Зарегистрирован |
|
|
|
|
|
