Отправлено: 30.04.10 10:34. Заголовок: Как сделать программу 64битной ?

Всем привет !
Только не пинайте сильно за вопрос... Пока только разбираюсь....

Как готовое приложение под хХарбором (терминалка) пересобрать на 64bit под новые системы Win 7 ?
Оно конечно и так там работает, но хотелось бы узнать что это даст ?

 Отправлено: 30.04.10 11:19. Заголовок: Надо собрать харбор ..

Надо собрать харбор каким-нибудь 64-битным С-компилятором: msvc64, Intel, Pelles C, mingw64
А что это даст - операции с типом данных longlong (64-битные целые) будут выполняться быстрее. Но такие значения используются редко, это целые числа со значением больше 2 млрд

 Отправлено: 30.04.10 12:07. Заголовок: А самые медленные оп..

А самые медленные операции, чтение-запись в базы будут быстрей происходить на 64bit приложениях ?
Т.е. расчет который проходит за 1.5 часа на 32bit приложении, будет быстрей производиться ?

 Отправлено: 30.04.10 12:36. Заголовок: Andrey пишет: Т.е. ..

Andrey пишет:

цитата:

Т.е. расчет который проходит за 1.5 часа на 32bit приложении

Каков размер базы (кол-во записей и полей которые участвуют в расчете ) , что так долго считается ?!

 Отправлено: 30.04.10 14:25. Заголовок: Dima пишет: Каков ..

Dima пишет:

цитата:

Каков размер базы (кол-во записей и полей которые участвуют в расчете ) , что так долго считается ?!

Да я уже писал про это... Все никак не дойдут руки до оптимизации...
База примерно 65 500 записей, объём 231 Мб, кол-во полей 374. Без МЕМО поля.
База содержит 30 полей:
1) даты прихода денег,
2) суммы прихода денег,
3) даты начисления,
4) суммы начисления,
.... короче лучше смотреть скриншот....

 Отправлено: 30.04.10 14:28. Заголовок: Andrey пишет: Все н..

Andrey пишет:

цитата:

Все никак не дойдут руки до оптимизации...

Помочь ? Одна голова хорошо а две лучше ;)

PS
С тебя пиво.

 Отправлено: 30.04.10 14:30. Заголовок: Andrey пишет: А сам..

Andrey пишет:

цитата:

А самые медленные операции, чтение-запись в базы будут быстрей происходить на 64bit приложениях ?

На эти операции разрядность ОС не влияет

 Отправлено: 30.04.10 14:56. Заголовок: Dima пишет: Каков ..

Dima пишет:

цитата:

Каков размер базы (кол-во записей и полей которые участвуют в расчете ) , что так долго считается ?!

Да я уже писал про это... Все никак не дойдут руки до оптимизации...
База примерно 65 500 записей, объём 231 Мб, кол-во полей 374. Без МЕМО поля.
База содержит 30 полей:
1) даты прихода денег,
2) суммы прихода денег,
3) даты начисления,
4) суммы начисления,
.... короче лучше смотреть скриншот....


Т.е. на ВСЕ начисления и приход денег абонента имею ВСЕГО ОДНУ запись в БД.
Это позволило еще в 1999году на Клипере 5.3 под Виндой95/98 просматривать "мгновенно" начисления абонента.
Правда считалось (раз в месяц) ну очень долго, часов 15-16....

Расчет происходил так:
1) создавалась временная база одного абонента,
2) туда копировались данные по одному абоненту из основной БД,
3) делалось начисления (добавлялись записи в временную БД),
4) считывались записи из временной БД в постоянную,
5) временная база закрывалась.

Сейчас делается немного по другому:
1) Считываются данные по одному абоненту из основной БД в многомерный массив,
2) делаются начисления в массиве (добавляются строки в массив и т.д.)
3) записываются значения из массива в основную БД.
4) массив удаляется.

Сейчас на хХарборе считается быстрей конечно, но от времени записи из массива в БД - никуда не денешься.
А это 30 полей "Даты прихода денег", 30 полей Суммы прихода денег", 30 полей "Даты начислений", 30 полей "Суммы начислений" и т.д.

Вот такой ПИРОГ получается ....

 Отправлено: 30.04.10 14:57. Заголовок: Dima пишет: С тебя ..

Dima пишет:

цитата:

С тебя пиво.

Без вопросов... Куда доставить... Адрес давай....

 Отправлено: 30.04.10 15:06. Заголовок: Andrey пишет: 1) Сч..

Andrey пишет:

цитата:

1) Считываются данные по одному абоненту из основной БД в многомерный массив, 2) делаются начисления в массиве (добавляются строки в массив и т.д.) 3) записываются значения из массива в основную БД. 4) массив удаляется.

100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай.

 Отправлено: 30.04.10 15:18. Заголовок: Andrey Алгоритм я т..

Andrey
Алгоритм я так понял не изменился , за исключением того что ранее инфа по абоненту считывалась во
временную базу а сегодня в маcсив.

Andrey пишет:

цитата:

Считываются данные по одному абоненту из основной БД в многомерный массив

Andrey пишет:

цитата:

Т.е. на ВСЕ начисления и приход денег абонента имею ВСЕГО ОДНУ запись в БД

То есть фактически считываются 374 поля из одной единственной записи ?
И если я верно понял то длина массива не более 374 элементов !?
Полтора часа не понятно что там можно считать.......

Andrey пишет:

цитата:

кол-во полей 374

Дни года что ли в полях хранишь ?

 Отправлено: 30.04.10 15:51. Заголовок: У нас же была тема п..

У нас же была тема про массивы. Операции с массивами тоже можно резко оптимизировать, но нужно видеть предмет для разговора
т.е. алгоритм.
Т.е., имеем простой цикл по таблице абонентов, и расчет по каждому абоненту выполняется за 1.5 часа/65000 абонентов, т.е грубо за 0.08 сек
Прежде всего надо выяснить узкое место. Это выборка данных из БД или сам расчет ?

 Отправлено: 30.04.10 17:38. Заголовок: По-моему - "узко..

По-моему - "узкое" место - это "широкая таблица" БД. Кажется, уже тут об этом писали.

 Отправлено: 01.05.10 14:55. Заголовок: Dima пишет: То есть..

Dima пишет:

цитата:

То есть фактически считываются 374 поля из одной единственной записи ? И если я верно понял то длина массива не более 374 элементов !?

Длина массива 15 элементов (как на скриншоте выше):
1) Тариф
2) Дата тарифа
3) Приход
4) Дата прихода
5) Вид оплаты
6) Начислено
7) Простили
8) Дата начисления
9) Задолжность
10) Номер документа оплаты
11) Номер пачки
12) Примечание
13) Id абонента
14) Id операции
15) Id резерв

Dima пишет:

цитата:

Дни года что ли в полях хранишь ?

Нет в одной записи храню по 30 значений:
Тариф, дата тарифа, сумма начисления, дата начисления, ... и т.д. до 13 позиции списка выше !
Плюс суда к этому 10-15 доп.полей, Id абонента, Дата последней корректировки, Признак закрытия начислений .. и т.д.

Pasha пишет:

цитата:

Прежде всего надо выяснить узкое место. Это выборка данных из БД или сам расчет ?

Расчет быстрый !
Узкое место запись (чтение не рассматриваю, т.к. эта операция быстрей) из массива в БД !
Т.е. надо из массива записать в поля записи по 30 значений:
Тарифа, даты тарифа, .... (см.выше)

У меня если юзер пересчитывает абонентскую плату ОДНОГО абонента, это мгновенно, да и запись одного абонента, тоже юзера НЕ НАПРЯГАЕТ, быстро происходит...

Почему сделано по 30 значений, отвечу. В принципе АБОНЕНТ за год оплачивает коммуналку 1 раз в месяц... Раньше база была меньше, хранил по 15 значений... Но жизнь показа (тут и ЕИРЦ и СБанк), что мало. Пришлось до 30 довести. Сейчас вообще прикол с этим ЕИРЦ в Москве - коммунальные услуги оплачивает каждый собственник квартиры. Семья - допустим из 4 человек платит каждый месяц по 4 платежа, итого 4*12=42 платежа .... Тут и 30 моих ячеек не хватает...

 Отправлено: 01.05.10 15:09. Заголовок: LYSK пишет: По-моем..

LYSK пишет:

цитата:

По-моему - "узкое" место - это "широкая таблица" БД. Кажется, уже тут об этом писали.

Согласен с этим высказыванием. Но другого пути в свое время (см.выше) я не увидел.
Что будет быстрей считаться я не знаю. Но в моей базе можно считать и больше 1 миллиона абонентов.
А в обычной базе сколько можно будет считать ? И сколько записей будет в этой БД ?
Допустим имеем 100 000 абонентов (я считал и 150тыс.абонентов). За год абонент платит 15 раз (см. выше, у меня чаще).
Плюс к этому еще и начисления, т.е. 15*2
Итого имеем 100000 * 15 * 2 = 3 000 000 записей.
Интересно сколько времени будет начисляться по такому кол-ву записей ?

 Отправлено: 06.05.10 20:50. Заголовок: Петр пишет: 100% пр..

Петр пишет:

цитата:

100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай.

А есть смысл переделать под эту штуку ?
И навскидку - какое будет ускорение ?

 Отправлено: 06.05.10 20:52. Заголовок: Andrey пишет: И нав..

Andrey пишет:

цитата:

И навскидку - какое будет ускорение ?

Просто попробуй и сравни сам по скорости с массивом. Потом нам раскажешь ;)

 Отправлено: 06.05.10 21:25. Заголовок: Andrey пишет: А ест..

Andrey пишет:

цитата:

А есть смысл переделать под эту штуку ?

? Если вы ее освоите и будете использовать, то почему и нет.

цитата:

И навскидку - какое будет ускорение ?

Автор hbmemio Mindaugas Kavaliauskas в принципе для таких целей и написал эту библиотеку. По его словам, время построения отчетов его программой уменьшилось ощутимо, в разы, но порядок цифр точно не помню, потому и приводить не буду.

 Отправлено: 06.05.10 21:32. Заголовок: Со своей стороны хоч..

Со своей стороны хочу добавить, что с в некоторых программах с той же целью я использую SQLITE in memory database (аналог hbmemio) - у пользователей создается ощущение, что все выполняется на 1-2

 Отправлено: 08.07.10 22:01. Заголовок: Попробуйтуе железо поменять :(

Андрей есть подозрение, что в Вашем случае переход на 64 бита ничего не даст.
Подобные скорости наблюдал при чтении из файлов построчно (да здравствует XML - технология 21 века), с последующей обработкой. Причем при модернизации железа положение улучшилось в разы. Апгрейдить пришлость все : процессор, 4 Г памяти , SCSI RAID5 (HW).

Для интереса посмотрите статистики. Возможно проблема на виду . Например процессор загружен на 100 %, или кол. обрашений к диску великовато.

Про грабли :) (Офф топ)

Почитайте здесь :

http://clipper.borda.ru/?1-1-0-00000155-000-0-0-1225096542<\/u><\/a>

За вопрос "как поменять компилятор?" могут и заклевать :).


Кстати Вы там интересовались насчет WinCe, устыдившись после всего высказанного, купил FWPPC (FiveWin Pocket PC edition). Имеются проблемы (кодировка , недоработки), но в целом рулит.

 Отправлено: 02.12.11 19:24. Заголовок: Петр пишет: Andrey ..

Петр пишет:

цитата:

Andrey пишет: цитата: 1) Считываются данные по одному абоненту из основной БД в многомерный массив, 2) делаются начисления в массиве (добавляются строки в массив и т.д.) 3) записываются значения из массива в основную БД. 4) массив удаляется. 100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай.

Поднимаю еще раз этот вопрос. Так как собрался с силами (время на праздниках будет) делать оптимизацию по своим начислениям.

Буду пробовать вариант с hbmemio. Придется наверно делать отдельную программу на Харборе.

Но хотелось бы уточнить, а через многопотоковость нельзя ли организовать расчет ?
1) Сделать отдельную функцию расчета
2) запустит 10 потоков расчета/записи ОДНОЙ записи в БД и пускай они считают сразу 10 записей.....

Т.е. программа будет считать последовательно не 1-ну запись в БД, а сразу 10 !!!
Ну ускорения в 10 раз конечно же не ожидаю, но быстрей же БАЗА должна считаться в целом ?

 Отправлено: 02.12.11 23:01. Заголовок: Пятничный оффтоп. Пр..

Пятничный оффтоп. Просто для того, чтобы сопоставить имеющиеся в наличии вычислительные мощности и решаемые ими задачи.
На запущенной на днях марсианской экспедиции MSL стоимостью 2.5 млрд. долларов, это примерно 80 млрд. рублей в текущих ценах, что примерно в 10 раз превыщает стоимость флагманской миссии Роскосмоса Фобос-Грунт, к моему огромному сожалению неудачной, цена которой 8 млдр. рублей, установлен компьютер с такими характеристиками:
Процессор 200MHz - 2 шт, 250 MB RAM, 2GB флэш-память.
На запущенных в 2003-м году мамрсианских роверах стоит процессор 25 MHZ, 128 MB RAM, и флешка 256 MB.
На меркурианском аппарате Messenger, запущенном в 2004-м - процессоры 25 и 10 MHZ и флешка 1 GB.
Сопоставьте уровень решаемых задач с задачей по учету домофонов.

Дополнил оффтоп

 Отправлено: 03.12.11 15:53. Заголовок: Pasha, а файлы dbf, ..

Pasha, а файлы dbf, открытые в основной программе ведь недоступны в других потоках и между потоками?

 Отправлено: 03.12.11 16:00. Заголовок: PSP пишет: открытые..

PSP пишет:

цитата:

открытые в основной программе ведь недоступны в других потоках

Доступны

 Отправлено: 03.12.11 16:51. Заголовок: PSP пишет: Pasha, а..

PSP пишет:

цитата:

Pasha, а файлы dbf, открытые в основной программе ведь недоступны в других потоках и между потоками?

См. примеры в harbour\tests\mt

Андрей, так в чем узкое место расчета ? Если это выборка из БД, то распределение по потокам мало что даст.
Если расчет запустить локально, не по сети, то он работает быстрее ?
А если расчет запустить одновременно 2 или несколько раз на одном компьютере, то общее время будет какое ? Это будет некоторая эмуляция многопоточности.

 Отправлено: 04.12.11 10:30. Заголовок: Pasha пишет: См. пр..

Pasha пишет:

цитата:

См. примеры

Уже посмотрел. :)

 Отправлено: 04.12.11 20:07. Заголовок: Pasha пишет: Андрей..

Pasha пишет:

цитата:

Андрей, так в чем узкое место расчета ?

Берется 1-я запись Абонента (из 30-65 тыс. записей)
1) Считываются данные по одному абоненту из основной БД в многомерный массив (структуру смотри выше),
2) делаются начисления в массиве (добавляются строки в массив и т.д.)
3) записываются значения из массива в основную БД (30 значений по столбцам: даты начислений, суммы начислений, ставок т/о и т.д. - итого 30*12=360 значениц в таблицу БД). - помоему самое узкое место....
4) массив удаляется.
Берется 2-я запись Абонента....

Pasha пишет:

цитата:

Если расчет запустить локально, не по сети, то он работает быстрее ?

Конечно быстрее, в несколько раз... Но не всегда это можно, т.к. у некоторых моих пользователей БАЗЫ сидят на выделенном сервере - они считают через локальную сеть- это раза в 2-3 дольше. А некоторые запускают задачу счета на сервере- все равно считаются абоненты 1,5-2 часа.

Pasha пишет:

цитата:

А если расчет запустить одновременно 2 или несколько раз на одном компьютере, то общее время будет какое ? Это будет некоторая эмуляция многопоточности.

Программа на компе запускается только в одно окно (т.е. стоит запрет на запуск второй копии програииы).
У меня стоит запрет на расчет несколькими рабочими станциями одновременно. Считает только ОДИН пользователь... Если допустить второго, то он тупо будет пересчитывать опять с 1-ой записи.

Для того чтоб разрешить считать нескольким программам, тогда наверно нужно делать отдельную функцию (журнал расчета): какая станция расчитывает абонента с номером ID и смотреть чтоб абонент уже не был уже расчитан.

Я просто хочу понять с вашей помощью, стоит ли тратить время на это или нужно по другому решать.

Если абонентов мало, т.е. меньше 30 тысяц - расчет быстро идет.
Просто у меня уже много контор где абонентов уже больше 50 тыс. - там медленно очень 1,5-2 часа.
Сервера у них разные, ХР/2003, 2 МГц и выше, памяти 2Гб. Средние машины...

Может нужно делать - отдельную программу на сервер (или службу/не знаю как пока), которая будет по "свистку" делать начисления ?

 Отправлено: 04.12.11 20:39. Заголовок: Andrey пишет: Счита..

Andrey пишет:

цитата:

Считает только ОДИН пользователь... Если допустить второго, то он тупо будет пересчитывать опять с 1-ой записи. Для того чтоб разрешить считать нескольким программам, тогда наверно нужно делать отдельную функцию (журнал расчета): какая станция расчитывает абонента с номером ID и смотреть чтоб абонент уже не был уже расчитан.

Потоки по сути - это отдельные программы. Они все (сколько б их не было) будут работать с одним набором данных. Поэтому, тебе придется придумывать механизм разделения, который позволит на 100% быть уверенным, что не останется необработанных или обработанных больше одного раза записей.
А вот когда такой механизм будет, тогда и о потоках можно говорить.

 Отправлено: 04.12.11 20:56. Заголовок: PSP пишет: А вот ко..

PSP пишет:

цитата:

А вот когда такой механизм будет, тогда и о потоках можно говорить.

Да механизм придумать несложно, главное чтобы быстрее считало !
Вот я и пытаюсь понять, что быстрей будет:
1) вариант с hbmemio
2) вариант с потоками

 Отправлено: 04.12.11 21:10. Заголовок: Andrey пишет: Pasha..

Andrey пишет:

цитата:

Pasha пишет: цитата: Если расчет запустить локально, не по сети, то он работает быстрее ? Конечно быстрее, в несколько раз...

Тогда напрашивается вариант с letodb. Функция расчета компилируется на сервере в файл hrb, и запускается на выполнение с клиента.
При этом расчет будет выполнять сервер, без всякой передачи данных по сети. Да еще БД при этом открывается сервером монопольно, так шта.. это будет еще быстрее.
Ну и конечно, надо пересмотреть код на предмет оптимизации. Опыт подсказывает, что здесь всегда есть резервы.

 Отправлено: 04.12.11 21:19. Заголовок: Да, Андрей, хотелось..

Да, Андрей, хотелось бы уточнить терминологию. Под термином "БД" ты имеешь в ввиду одну таблицу БД ? И одному абоненту в этой таблице соответствует одна запись ? И результат расчета записывается в эту строку (запись) ? И все это работает мееедленно ? Я правильно понимаю ?
Структура простейшая, без всяких связей, подчиненных таблиц, и прочего ?
Тогда мне не очень понятно, что там может быть медленно ? Если ты думаешь, что это запись результата, то это всего лишь операция dbCommit.
Или все-таки неоптимальный алгоритм расчета ?

 Отправлено: 04.12.11 21:27. Заголовок: Pasha пишет: Тогда ..

Pasha пишет:

цитата:

Тогда напрашивается вариант с letodb

На LetoDB пока не могу перейти:
1) LetoDB не поддерживает несколько индексных файлов для одной БД.
2) LetoDB не позволяет открывать сторонним программам уже открытые ей базы.
3) Переделка на LetoDB и перевод пользователей на нее пока проблематична из-за нехватки времени. В планах на 2012 год.

Ищу пока промежуточный вариант - запуск на сервере, отдельной программой:
1) вариант с hbmemio
2) вариант с потоками

Что будет быстрей работать ?

Pasha пишет:

цитата:

Ну и конечно, надо пересмотреть код на предмет оптимизации. Опыт подсказывает, что здесь всегда есть резервы.

Согласен. Но наверно для этого я пока отделю весь расчет в отдельный проект.
Соберу заодно и на Харборе. Посмотрю заодно кто быстрей считает...

 Отправлено: 04.12.11 21:53. Заголовок: 1. Я же это сделал у..

1. Я же это сделал уже почти месяц как.
2. Это не так, позволяет. Хотя при этом теряются преимущества монопольного доступа. Если сторонние программы твои, то лучше их тоже переделать c letodb
3. Ну тут тебе никто не поможет.

Что будет быстрее работать тебе никто не скажет, пока ты не покажешь свой расчет. Если ты считаешь, что узкое место - запись результата, то распределение по потокам не поможет. А для чего предполагается использовать hbmemio ? Вместо использования массива ? Так это называется менять шило на мыло. Хотя, конечно, и работу с массивами можно сделать так, что будет работать мееедленно. Я много неоптимального кода видел.

 Отправлено: 04.12.11 22:48. Заголовок: Pasha пишет: Я мног..

Pasha пишет:

цитата:

Я много неоптимального кода видел

+1

 Отправлено: 05.12.11 01:22. Заголовок: Pasha пишет: Под те..

Pasha пишет:

цитата:

Под термином "БД" ты имеешь в ввиду одну таблицу БД ? И одному абоненту в этой таблице соответствует одна запись ? И результат расчета записывается в эту строку (запись) ? И все это работает мееедленно ? Я правильно понимаю ?

Нет не одна таблица.
БД-Тарифов (даты и суммы начислений)
БД-Абонент (1 запись, в ней ID-абонента, его тариф).
По тарифу вытаскиваю из БД-Тарифа сумму начисления за месяц.
По ID-абонента, seek-ом иду на БД-оплаты-20хх года.
Далее считываю 30*12=360 значений БД в массив,
далее делаю начисления,
блокирую запись БД-оплаты-20хх и переписываю массив 30*12=360 значений в эту запись.
Далее блокирую запись БД-Абонента и записываю итог и дату расчета этого абонента.

Вот в кратце "алгоритм".

Я выводил счет времени по одному абоненту. Где то среднее 0.08 сек счета по одному абоненту.
Много помоему...

Может "зарубить" вывод на экран "бегунка" по каждому абоненту ?
Перерисовка экрана в GTWVT-терминалке времени тоже же "отнимает" порядочно !

 Отправлено: 05.12.11 10:13. Заголовок: Имхо, весь затык в п..

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

 Отправлено: 05.12.11 12:31. Заголовок: PSP пишет: Нет не о..

PSP пишет:

цитата:

Нет не одна таблица. БД-Тарифов (даты и суммы начислений) БД-Абонент (1 запись, в ней ID-абонента, его тариф). По тарифу вытаскиваю из БД-Тарифа сумму начисления за месяц. По ID-абонента, seek-ом иду на БД-оплаты-20хх года. Далее считываю 30*12=360 значений БД в массив, далее делаю начисления, блокирую запись БД-оплаты-20хх и переписываю массив 30*12=360 значений в эту запись. Далее блокирую запись БД-Абонента и записываю итог и дату расчета этого абонента. Вот в кратце "алгоритм". Я выводил счет времени по одному абоненту. Где то среднее 0.08 сек счета по одному абоненту. Много помоему...

0.08 это много. 0.08*65000 = 5200 сек

Каким методом выбираются оплаты ?
Быстрым индексно-последовательным, т.е.
seek
while ! eof() .and. ...
skip
enddo

или более медленным индексным, т.е.
seek
seek
...

?

Что записывается в оплаты и как, каким методом ?
И зачем при расчете что-то заносить в оплаты ? Оплаты это оплаты, а расчет это расчет.

Все-таки, где узкое место ?
Если сделать отдельно расчет без записи, и запись чего-нибудь без расчета, то что медленнее ?

 Отправлено: 05.12.11 15:17. Заголовок: А что является резул..

А что является результатом расчета? Сумма к оплате?
Если да, то чем вызвана необходимость перезаписи всего массива из 360 эл-тов?

 Отправлено: 05.12.11 19:46. Заголовок: Результативнее перес..

Результативнее пересмотреть алгоритм расчета , по аналогии с 1с. Результат m1+m2+m3+m4 =S1_4
можно заменить на S1_3 +m4 =S1_4 где S1_3 =m1+m2+m3. Т.е вводятся промежуточные итоги. Общий итог равен ближайший промежуточный + данные за текущий период. Название 1с означает - ПОЛУЧИТЬ РЕЗУЛЬТАТ ЗА 1 секунду.

 Отправлено: 05.12.11 21:01. Заголовок: Vlad04 пишет: Назва..

Vlad04 пишет:

цитата:

Название 1с означает - ПОЛУЧИТЬ РЕЗУЛЬТАТ ЗА 1 секунду.

 Отправлено: 05.12.11 21:12. Заголовок: У меня на 1с7(дбф) з..

У меня на 1с7(дбф) зарплата на 40 чел рассчитывается около минуты, а на clipper5.3 для 260 чел приблизительно 20 сек., так что 1с в аналогии брать не нужно.

 Отправлено: 05.12.11 21:29. Заголовок: Pasha пишет: Каким ..

Pasha пишет:

цитата:

Каким методом выбираются оплаты ?

Andrey пишет:

цитата:

По ID-абонента, seek-ом иду на БД-оплаты-20хх года.

SELECT PLATA2011
DBSETORDER(1)
GOTO TOP
SEEK (ID-абонента)

Pasha пишет:

цитата:

Что записывается в оплаты и как, каким методом ?

После расчета, запись массива WritDimDbf(aMassiv,.F., @cError)
Скрытый текст

********************************************************* FUNCTION WritDimDbf(aMassiv,lSee,cError) LOCAL cTemp, nJ, nSum, nY:=MAXROW(), nX:=0, nRazr DEFAULT lSee TO .T. cError := "" FOR nJ := 1 TO 30 IF lSee cTemp:="Записываю записи: "+STR(nJ,2) @ nY,nX SAY PADC(cTemp,80) COLOR("14/5") ENDIF cTemp:="Tarif"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) nSum := aMassiv[nJ,A_TARIF] // Тариф "N" , 6,2 nRazr:= FIELDSIZE(FIELDNUM(cTemp)) IF nRazr < LEN(ALLTRIM(STR(nSum))) cError:=cError+'Нехватает разрядности поля "'+cTemp+'" <-'+STR(nSum)+; " [размерность поля ="+; ALLTRIM(STR(nRazr))+" - размерность запис.значения ="+; ALLTRIM(STR(LEN(ALLTRIM(STR(nSum)))))+"]"+CRLF FIELD->&cTemp := -1 ELSE FIELD->&cTemp := nSum ENDIF cTemp:="TarDat"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_TARDAT] // Дата Тарифа "D" , 8,0 cTemp:="Prixod"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) nSum := aMassiv[nJ,A_PRIXOD] // Приход "N" , 6,2 nRazr:= FIELDSIZE(FIELDNUM(cTemp)) IF nRazr < LEN(ALLTRIM(STR(nSum))) cError:=cError+'Нехватает разрядности поля "'+cTemp+'" <-'+STR(nSum)+; " [размерность поля ="+; ALLTRIM(STR(nRazr))+" - размерность запис.значения ="+; ALLTRIM(STR(LEN(ALLTRIM(STR(nSum)))))+"]"+CRLF FIELD->&cTemp := -1 ELSE FIELD->&cTemp := nSum ENDIF cTemp:="PriDat"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_PRIDAT] // Дата Прихода "D" cTemp:="Koplata"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_KOPLATA] //Вид оплаты cTemp:="Nachis"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) nSum := aMassiv[nJ,A_NACHIS] // Начислено "N" , 6,2 nRazr:= FIELDSIZE(FIELDNUM(cTemp)) IF nRazr < LEN(ALLTRIM(STR(nSum))) cError:=cError+'Нехватает разрядности поля "'+cTemp+'" <-'+STR(nSum)+; " [размерность поля ="+; ALLTRIM(STR(nRazr))+" - размерность запис.значения ="+; ALLTRIM(STR(LEN(ALLTRIM(STR(nSum)))))+"]"+CRLF FIELD->&cTemp := -1 ELSE FIELD->&cTemp := nSum ENDIF cTemp:="Dobavka"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) nSum := aMassiv[nJ,A_DOBAVKA] // Добавление к Начислено "N" , 6,2 nRazr:= FIELDSIZE(FIELDNUM(cTemp)) IF nRazr < LEN(ALLTRIM(STR(nSum))) cError:=cError+'Нехватает разрядности поля "'+cTemp+'" <-'+STR(nSum)+; " [размерность поля ="+; ALLTRIM(STR(nRazr))+" - размерность запис.значения ="+; ALLTRIM(STR(LEN(ALLTRIM(STR(nSum)))))+"]"+CRLF FIELD->&cTemp := -1 ELSE FIELD->&cTemp := nSum ENDIF cTemp:="NacDat"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_NACDAT] // Дата Начисления "D" cTemp:="Dolg"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) nSum := aMassiv[nJ,A_DOLG ] // Задолжность "N" , 7,2 nRazr:= FIELDSIZE(FIELDNUM(cTemp)) IF nRazr < LEN(ALLTRIM(STR(nSum))) cError:=cError+'Нехватает разрядности поля "'+cTemp+'" <-'+STR(nSum)+; " [размерность поля ="+; ALLTRIM(STR(nRazr))+" - размерность запис.значения ="+; ALLTRIM(STR(LEN(ALLTRIM(STR(nSum)))))+"]"+CRLF FIELD->&cTemp := -1 ELSE FIELD->&cTemp := nSum ENDIF cTemp:="Docum"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_DOCUM] // No документа оплаты "C" 20,0 cTemp:="Box"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_BOX] // No пачки "C" 8,0 cTemp:="Rem"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_REM] // Комментарий "C" 8,0 NEXT RETURN NIL

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

 Отправлено: 05.12.11 22:45. Заголовок: Я уже устал напрягат..

Я уже устал напрягать свои и без того неразвитые телепатические способности :)
Итак, что же мне удалось расшифровать:
Имеется широоооокая таблица (не БД, давай все-таки использовать общепринятую, а не безграмотную терминологию) абонентов, назовем ее TA.
Что хранится в ТА ? Все данные со всеми начислениями за все годы ? В чем заключается расчет ?
Имеется какая-то таблица тарифов (назовем ее TT). Какова ее структура ? Что там, виды услуг, тарифы с изменением по периодам времени ? Как из нее выбираются записи ?
Тарифы выбираются в основном цикле по абонентам ?
Имеется таблица оплат (назовем ее TO aka PLATA2011). Она хранит в одной записи все оплаты абонента за 10 лет по месяцам ? Или за 1 год ?
Что такое 30 ? В приведенной процедуре просто сбрасывается какая-то одна запись.
Зачем выполняется магическое действие сначала считывания из таблицы в массив, а затем запись из массива в таблицу каких-то данных ? Это одни и те же данные ? Зачем их гонять туда-сюда ?
Что и как хранится отдельно по каждому подьезду и заносится в, хм, БД, Договора ?
Для чего ты собрался использовать hbmemio ? Вместо массива 12*30, что ли ? Так это же полный абсурд.
Андрей, моих способностей гадалки, телепата и экстрасенса недостаточно. Если хочешь какой-то помощи - подробно опиши свой алгоритм, со всеми выполняемыми действиями.
Ну а нет - так нет.

Пару слов про использование массива.
1. В цикле можно использовать промежуточную переменную:

amj := aMassiv[nJ]

и затем вместо aMassiv[nJ,A_TARIF] использовать amj[A_TARIF], и так для всех 12-ти элементов

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

Впрочем, думается, это даст немного. Узкое место еще ведь не выяснено.
Хотя, конечно, можно использовать чудесный "метод подитогов" из 1С. Это сразу волшебным образом сократит время всего расчета до 1-й секунды.

 Отправлено: 06.12.11 00:08. Заголовок: Pasha пишет: Я уже ..

Pasha пишет:

цитата:

Я уже устал напрягать свои и без того неразвитые телепатические способности :)

Ну извини, не хотел сильно нагружать !

Pasha пишет:

цитата:

Имеется таблица оплат (назовем ее TO aka PLATA2011). Она хранит в одной записи все оплаты абонента за 10 лет по месяцам ? Или за 1 год ? Что такое 30 ? В приведенной процедуре просто сбрасывается какая-то одна запись.

Одна запись хранит приходы денег, даты прихода денег, даты начисления и сумму начисления и т.д. за ОДИН год.
30 записей за год (т.к. я писал ранее про "ерунду" творящуюся при перечислении денег) и 12 записей не хватает на год.

Pasha пишет:

цитата:

Зачем выполняется магическое действие сначала считывания из таблицы в массив, а затем запись из массива в таблицу каких-то данных ? Это одни и те же данные ? Зачем их гонять туда-сюда ?

Данные по абоненту, у которого различается тариф оплаты, сумма оплаты, сумма и дата прихода денег и т.д. - все загоняется в массив, далее делаем начисления (пересчет с начала года, мало ли что было: изменили тариф, ставки тех.обсл.), далее записываем массив в поля ОДНОЙ записи таблицы.

Pasha пишет:

цитата:

Что и как хранится отдельно по каждому подьезду и заносится в, хм, БД, Договора ?

Это пока несущественно.

Pasha пишет:

цитата:

Для чего ты собрался использовать hbmemio ? Вместо массива 12*30, что ли ? Так это же полный абсурд.

Хочу всю таблицу ТА записать в память, потом сделать начисления, а потом сбросить в таблицу ТА уже с расчетами на диск.

Pasha пишет:

цитата:

Андрей, моих способностей гадалки, телепата и экстрасенса недостаточно. Если хочешь какой-то помощи - подробно опиши свой алгоритм, со всеми выполняемыми действиями.

Понятно, что трудно понять чужую тематику (я сам уже в этот алгоритм 5 лет не лез, как с Клипера перенес) и с такими моими "куцими" объяснениями. Но я хотел не углубляться в код и не грузить вас этим.
Придется наверно все-таки подробно ВСЕ описать. Но на это нужно время.
Пока беру паузу для подготовки описания алгоритма. Чуть позже напишу.
Спасибо за помощь !!!

 Отправлено: 06.12.11 00:12. Заголовок: PSP пишет: Имхо, ве..

PSP пишет:

цитата:

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

Andrey пишет:

цитата:

Ищу пока промежуточный вариант - запуск на сервере, отдельной программой !

Я хочу пока отдельную программу сделать !!!
А уже потом Letodb прикручивать....

 Отправлено: 06.12.11 10:53. Заголовок: Andrey пишет: Хочу ..

Andrey пишет:

цитата:

Хочу всю таблицу ТА записать в память, потом сделать начисления, а потом сбросить в таблицу ТА уже с расчетами на диск.

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

 Отправлено: 06.12.11 12:01. Заголовок: Pasha пишет: Да и к..

Pasha пишет:

цитата:

Да и к тому же держать в памяти сотни мегабайт или более данных на пользу не пойдет в любом случае.

Спасибо большое !

 Отправлено: 06.12.11 12:05. Заголовок: Андрей, не знаю тонк..

Андрей, не знаю тонкостей твоего алгоритма, но:

Pasha пишет:

цитата:

записывать по одному будет быстрее

В моей программе по расчету зарплаты пункта "Расчет" нет в принципе. При вводе бухгалтером любого начисления автоматически выполняется полный перерасчет по человеку. О плюсах и минусах такого подхода можно, конечно, спорить. Но могу сказать, что расчет выполняется мгновенно, БД всегда в актуальном состоянии.
В твоем случае, когда перерасчет по человеку выполняется за 0.08 с, все это будет происходить незаметно даже без изменения существующего механизма обработки.

 Отправлено: 06.12.11 12:07. Заголовок: S-A-N пишет: При вв..

S-A-N пишет:

цитата:

При вводе бухгалтером любого начисления автоматически выполняется полный перерасчет по человеку.

Тоже интересный вариант.

 Отправлено: 06.12.11 12:16. Заголовок: Насколько я понимаю,..

Насколько я понимаю, здесь несколько другая специфика. Данные для начислений есть изначально, а вводятся только немногочисленные изменения. Так что без общего расчета не обойтись.

 Отправлено: 06.12.11 13:08. Заголовок: Pasha пишет: без об..

Pasha пишет:

цитата:

без общего расчета не обойтись

Расчета чего? Суммы к оплате? А зачем ее хранить? Насколько я понимаю тариф - это условно постоянная величина, которую нет смысла дублировать (12 мес.) * (кол-во лет) * (кол-во абонентов) раз. Речь может идти только о хранении информации об оплате и льготах (если есть). Тогда при выводе информации (на принтер или монитор) о текущем состоянии расчетов с абонентом сумму к оплате можно получать динамически.

Если есть необходимость эту информацию разносить по другим таблицам, то это можно делать во время печати квитанций на оплату. "Тормозов" в расчете не будет, поскольку печать более медленная операция.

И о структуре таблицы оплат. Андрей, а что будет, если абонент будет вносить оплату не одной, а 2-3-... суммами ежемесячно? Не проще ли хранить информацию в виде ID абона, дата оплаты, сумма, за какой период, прочая сопроводительная инфа.

Хотя, опять же, не зная постановки задачи, трудно рассуждать.

 Отправлено: 06.12.11 15:27. Заголовок: S-A-N пишет: И о ст..

S-A-N пишет:

цитата:

И о структуре таблицы оплат. Андрей, а что будет, если абонент будет вносить оплату не одной, а 2-3-... суммами ежемесячно? Не проще ли хранить информацию в виде ID абона, дата оплаты, сумма, за какой период, прочая сопроводительная инфа.

Вот из-за этого и сделано 30 граф для прихода денег PLATA2011 (почитай выше).
А информация так и храниться в отдельной базе прихода денег (таблица оплат) по записям: 1запись - 1 приход денег.

Когда деньги за текущий месяц закончили приходить из банка, РКЦ и т.д. то делаем перенос денег по конкретным абонентам (в таблицу PLATA2011 в свободную ячейку), а потом уж делаем расчет (начисление) по всей таблице абонентов (ТА).
Из-за этого раз в месяц нужно делать ОБЩИЙ расчет.
После этого и делается печать долгов, печать квитанций и т.д., следуя специфики предприятия. Они все делают по разному, одни печатают, другие не печатают... их трудно понять....

Я на этой задаче 12 год сижу. Делал на Клипере 5.3 под Новел, потом перевел на хХарбор.
Сейчас бы конечно сделал бы по другому, но тогда компы были очень слабыми, а Клипер шустро считал и выдавал сведения.
А пределать что-то по другому в работающей программе - это целая ЭПОПЕЯ, всем сразу становится неудобно, шумят, что раньше понятней было и цвет лучше был и т.д. Одна морока по переводу....
Это если с нуля новому предприятию даешь новую программу, то все нормально, привыкают сразу.

 Отправлено: 06.12.11 15:38. Заголовок: Andrey пишет: А инф..

Andrey пишет:

цитата:

А информация так и храниться в отдельной базе прихода денег (таблица оплат) по записям: 1запись - 1 приход денег. Когда деньги за текущий месяц закончили приходить из банка, РКЦ и т.д. то делаем перенос денег по конкретным абонентам (в таблицу PLATA2011 в свободную ячейку), а потом уж делаем расчет (начисление) по всей таблице абонентов (ТА). Из-за этого раз в месяц нужно делать ОБЩИЙ расчет.

А зачем что-то куда-то переносить ? В таблице оплат достаточно иметь индекс по ID абонента и дате оплаты: Str(ID)+DTOS(Date), и по нему всегда можно выбрать оплату за произвольный промежуток времени.
Если бы использовался letodb, это можно было бы сделать одним вызовом leto_Sum()

 Отправлено: 06.12.11 16:11. Заголовок: Pasha пишет: А заче..

Pasha пишет:

цитата:

А зачем что-то куда-то переносить ? В таблице оплат достаточно иметь индекс по ID абонента и дате оплаты

Вот-вот. И я о том же. Причем это будет работать лучше, чем сейчас даже без Leto DB (это, если нет времени переходить на него).

 Отправлено: 14.12.11 03:19. Заголовок: Pasha пишет: Для че..

Pasha пишет:

цитата:

Для чего ты собрался использовать hbmemio ? Вместо массива 12*30, что ли ? Так это же полный абсурд.

Ну я ему посоветовал.. Но в тот момент я не знал, что и как Андрей собирается делать. И теперь не совсем понимаю логику его действий.
А код WritDimDbf вообще вызывает улыбку

 Отправлено: 14.12.11 09:56. Заголовок: Да, судя по всему, п..

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

 Отправлено: 14.12.11 11:18. Заголовок: Pasha пишет: Да, су..

Pasha пишет:

цитата:

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

А я разве спорю ? Это делалось еще в 1998 году, я про это писал уже....

Andrey пишет:

цитата:

Я на этой задаче 12 год сижу. Делал на Клипере 5.3 под Новел, потом перевел на хХарбор. Сейчас бы конечно сделал бы по другому, но тогда компы были очень слабыми, а Клипер шустро считал и выдавал сведения.

Петр пишет:

цитата:

А код WritDimDbf вообще вызывает улыбку

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

 Отправлено: 15.12.11 18:46. Заголовок: Andrey пишет: Я на ..

Andrey пишет:

цитата:

Я на этой задаче 12 год сижу. Делал на Клипере 5.3 под Новел, потом перевел на хХарбор. Сейчас бы конечно сделал бы по другому,

Так в чём проблема?