Отправлено: 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 раз конечно же не ожидаю, но быстрей же БАЗА должна считаться в целом ?