Как сделать программу 64битной ?

Форум » [x]Harbour » Как сделать программу 64битной ? » Ответить

Как сделать программу 64битной ?

Andrey: Всем привет ! Только не пинайте сильно за вопрос... Пока только разбираюсь.... Как готовое приложение под хХарбором (терминалка) пересобрать на 64bit под новые системы Win 7 ? Оно конечно и так там работает, но хотелось бы узнать что это даст ?

Ответов - 57, стр: 1 2 3 All

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

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

Dima: Andrey пишет: Т.е. расчет который проходит за 1.5 часа на 32bit приложении Каков размер базы (кол-во записей и полей которые участвуют в расчете ) , что так долго считается ?!

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

Dima: Andrey пишет: Все никак не дойдут руки до оптимизации... Помочь ? Одна голова хорошо а две лучше ;) PS С тебя пиво.

Pasha: Andrey пишет: А самые медленные операции, чтение-запись в базы будут быстрей происходить на 64bit приложениях ? На эти операции разрядность ОС не влияет

Andrey: 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 полей "Суммы начислений" и т.д. Вот такой ПИРОГ получается ....

Andrey: Dima пишет: С тебя пиво. Без вопросов... Куда доставить... Адрес давай....

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

Dima: Andrey Алгоритм я так понял не изменился , за исключением того что ранее инфа по абоненту считывалась во временную базу а сегодня в маcсив. Andrey пишет: Считываются данные по одному абоненту из основной БД в многомерный массив Andrey пишет: Т.е. на ВСЕ начисления и приход денег абонента имею ВСЕГО ОДНУ запись в БД То есть фактически считываются 374 поля из одной единственной записи ? И если я верно понял то длина массива не более 374 элементов !? Полтора часа не понятно что там можно считать....... Andrey пишет: кол-во полей 374 Дни года что ли в полях хранишь ?

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

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

Andrey: 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 моих ячеек не хватает...

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

Andrey: Петр пишет: 100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай. А есть смысл переделать под эту штуку ? И навскидку - какое будет ускорение ?

Dima: Andrey пишет: И навскидку - какое будет ускорение ? Просто попробуй и сравни сам по скорости с массивом. Потом нам раскажешь ;)

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

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

XVar: Андрей есть подозрение, что в Вашем случае переход на 64 бита ничего не даст. Подобные скорости наблюдал при чтении из файлов построчно (да здравствует XML - технология 21 века), с последующей обработкой. Причем при модернизации железа положение улучшилось в разы. Апгрейдить пришлость все : процессор, 4 Г памяти , SCSI RAID5 (HW). Для интереса посмотрите статистики. Возможно проблема на виду . Например процессор загружен на 100 %, или кол. обрашений к диску великовато. Про грабли :) (Офф топ) Почитайте здесь : http://clipper.borda.ru/?1-1-0-00000155-000-0-0-1225096542 За вопрос "как поменять компилятор?" могут и заклевать :). Кстати Вы там интересовались насчет WinCe, устыдившись после всего высказанного, купил FWPPC (FiveWin Pocket PC edition). Имеются проблемы (кодировка , недоработки), но в целом рулит.

Andrey: Петр пишет: Andrey пишет: цитата: 1) Считываются данные по одному абоненту из основной БД в многомерный массив, 2) делаются начисления в массиве (добавляются строки в массив и т.д.) 3) записываются значения из массива в основную БД. 4) массив удаляется. 100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай. Поднимаю еще раз этот вопрос. Так как собрался с силами (время на праздниках будет) делать оптимизацию по своим начислениям. Буду пробовать вариант с hbmemio. Придется наверно делать отдельную программу на Харборе. Но хотелось бы уточнить, а через многопотоковость нельзя ли организовать расчет ? 1) Сделать отдельную функцию расчета 2) запустит 10 потоков расчета/записи ОДНОЙ записи в БД и пускай они считают сразу 10 записей..... Т.е. программа будет считать последовательно не 1-ну запись в БД, а сразу 10 !!! Ну ускорения в 10 раз конечно же не ожидаю, но быстрей же БАЗА должна считаться в целом ?

Pasha: Пятничный оффтоп. Просто для того, чтобы сопоставить имеющиеся в наличии вычислительные мощности и решаемые ими задачи. На запущенной на днях марсианской экспедиции 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. Сопоставьте уровень решаемых задач с задачей по учету домофонов. Дополнил оффтоп

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

Dima: PSP пишет: открытые в основной программе ведь недоступны в других потоках Доступны

Pasha: PSP пишет: Pasha, а файлы dbf, открытые в основной программе ведь недоступны в других потоках и между потоками? См. примеры в harbour\tests\mt Андрей, так в чем узкое место расчета ? Если это выборка из БД, то распределение по потокам мало что даст. Если расчет запустить локально, не по сети, то он работает быстрее ? А если расчет запустить одновременно 2 или несколько раз на одном компьютере, то общее время будет какое ? Это будет некоторая эмуляция многопоточности.

PSP: Pasha пишет: См. примеры Уже посмотрел. :)

Andrey: 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Гб. Средние машины... Может нужно делать - отдельную программу на сервер (или службу/не знаю как пока), которая будет по "свистку" делать начисления ?

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

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

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

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

Andrey: Pasha пишет: Тогда напрашивается вариант с letodb На LetoDB пока не могу перейти: 1) LetoDB не поддерживает несколько индексных файлов для одной БД. 2) LetoDB не позволяет открывать сторонним программам уже открытые ей базы. 3) Переделка на LetoDB и перевод пользователей на нее пока проблематична из-за нехватки времени. В планах на 2012 год. Ищу пока промежуточный вариант - запуск на сервере, отдельной программой: 1) вариант с hbmemio 2) вариант с потоками Что будет быстрей работать ? Pasha пишет: Ну и конечно, надо пересмотреть код на предмет оптимизации. Опыт подсказывает, что здесь всегда есть резервы. Согласен. Но наверно для этого я пока отделю весь расчет в отдельный проект. Соберу заодно и на Харборе. Посмотрю заодно кто быстрей считает...

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

Dima: Pasha пишет: Я много неоптимального кода видел +1

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

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

Pasha: 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 ... ? Что записывается в оплаты и как, каким методом ? И зачем при расчете что-то заносить в оплаты ? Оплаты это оплаты, а расчет это расчет. Все-таки, где узкое место ? Если сделать отдельно расчет без записи, и запись чего-нибудь без расчета, то что медленнее ?

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

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

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

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

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

Pasha: Я уже устал напрягать свои и без того неразвитые телепатические способности :) Итак, что же мне удалось расшифровать: Имеется широоооокая таблица (не БД, давай все-таки использовать общепринятую, а не безграмотную терминологию) абонентов, назовем ее 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-й секунды.

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

Andrey: PSP пишет: Имхо, весь затык в постоянной передаче по сети. Letodb может помочь. Попробуй на копии рабочей базы. Там-то много не нужно переделывать. Andrey пишет: Ищу пока промежуточный вариант - запуск на сервере, отдельной программой ! Я хочу пока отдельную программу сделать !!! А уже потом Letodb прикручивать....

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

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

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

AlexMyr: S-A-N пишет: При вводе бухгалтером любого начисления автоматически выполняется полный перерасчет по человеку. Тоже интересный вариант.

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

S-A-N: Pasha пишет: без общего расчета не обойтись Расчета чего? Суммы к оплате? А зачем ее хранить? Насколько я понимаю тариф - это условно постоянная величина, которую нет смысла дублировать (12 мес.) * (кол-во лет) * (кол-во абонентов) раз. Речь может идти только о хранении информации об оплате и льготах (если есть). Тогда при выводе информации (на принтер или монитор) о текущем состоянии расчетов с абонентом сумму к оплате можно получать динамически. Если есть необходимость эту информацию разносить по другим таблицам, то это можно делать во время печати квитанций на оплату. "Тормозов" в расчете не будет, поскольку печать более медленная операция. И о структуре таблицы оплат. Андрей, а что будет, если абонент будет вносить оплату не одной, а 2-3-... суммами ежемесячно? Не проще ли хранить информацию в виде ID абона, дата оплаты, сумма, за какой период, прочая сопроводительная инфа. Хотя, опять же, не зная постановки задачи, трудно рассуждать.

Andrey: S-A-N пишет: И о структуре таблицы оплат. Андрей, а что будет, если абонент будет вносить оплату не одной, а 2-3-... суммами ежемесячно? Не проще ли хранить информацию в виде ID абона, дата оплаты, сумма, за какой период, прочая сопроводительная инфа. Вот из-за этого и сделано 30 граф для прихода денег PLATA2011 (почитай выше). А информация так и храниться в отдельной базе прихода денег (таблица оплат) по записям: 1запись - 1 приход денег. Когда деньги за текущий месяц закончили приходить из банка, РКЦ и т.д. то делаем перенос денег по конкретным абонентам (в таблицу PLATA2011 в свободную ячейку), а потом уж делаем расчет (начисление) по всей таблице абонентов (ТА). Из-за этого раз в месяц нужно делать ОБЩИЙ расчет. После этого и делается печать долгов, печать квитанций и т.д., следуя специфики предприятия. Они все делают по разному, одни печатают, другие не печатают... их трудно понять.... Я на этой задаче 12 год сижу. Делал на Клипере 5.3 под Новел, потом перевел на хХарбор. Сейчас бы конечно сделал бы по другому, но тогда компы были очень слабыми, а Клипер шустро считал и выдавал сведения. А пределать что-то по другому в работающей программе - это целая ЭПОПЕЯ, всем сразу становится неудобно, шумят, что раньше понятней было и цвет лучше был и т.д. Одна морока по переводу.... Это если с нуля новому предприятию даешь новую программу, то все нормально, привыкают сразу.

Pasha: Andrey пишет: А информация так и храниться в отдельной базе прихода денег (таблица оплат) по записям: 1запись - 1 приход денег. Когда деньги за текущий месяц закончили приходить из банка, РКЦ и т.д. то делаем перенос денег по конкретным абонентам (в таблицу PLATA2011 в свободную ячейку), а потом уж делаем расчет (начисление) по всей таблице абонентов (ТА). Из-за этого раз в месяц нужно делать ОБЩИЙ расчет. А зачем что-то куда-то переносить ? В таблице оплат достаточно иметь индекс по ID абонента и дате оплаты: Str(ID)+DTOS(Date), и по нему всегда можно выбрать оплату за произвольный промежуток времени. Если бы использовался letodb, это можно было бы сделать одним вызовом leto_Sum()

S-A-N: Pasha пишет: А зачем что-то куда-то переносить ? В таблице оплат достаточно иметь индекс по ID абонента и дате оплаты Вот-вот. И я о том же. Причем это будет работать лучше, чем сейчас даже без Leto DB (это, если нет времени переходить на него).

Петр: Pasha пишет: Для чего ты собрался использовать hbmemio ? Вместо массива 12*30, что ли ? Так это же полный абсурд. Ну я ему посоветовал.. Но в тот момент я не знал, что и как Андрей собирается делать. И теперь не совсем понимаю логику его действий. А код WritDimDbf вообще вызывает улыбку

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

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

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

полная версия страницы