Clarion 11-12

[Игорь Столяров]

64 бит в кларионе

Обратите внимание, что тема x64 приложений возникла впервые в крайнем посте RZ.
В отличии от поддержки Unicode, об этом никто не просил, да и зачем адресация более 4 GByte
в приложениях Clarion не совсем понятно. По моему просто уже нет фантазии и всё остальное уже обещали.

[Губин Игорь]

да и зачем адресация более 4 GByte

Нужна. Я писал, что уже сейчас некоторые IMDD и LogOut зашкаливают за 2Гб, что приводит к шизе кларионовского менеджера памяти и фактическому зависанию приложения. Доходит до того, что проще отказаться от LogOut, т.к. SSD винты имеют достаточную скорость.

[Игорь Столяров]

Доходит до того, что проще отказаться от LogOut

Ну если Вы можете отказать от Logout, то что мешает его разбить на блоки ?
Я понимаю, что есть направления, где x64 приложения востребованы.
И у AnyScreen тоже есть пользователи (не путать с покупателями !).
Просто их кол-во как тот суслик:

[Губин Игорь]

Ну если Вы можете отказать от Logout, то что мешает его разбить на блоки ?

А выигрыша, практически, и не получается. Слишком много слишком маленьких блоков. Основная проблема в том, что выигрыш с LogOut получается, на моём приложении, когда он больше (чем больше - тем лучше) 500Мб (а при 1Гб начинаются проблемы с менеджером). Сколько записей надо "отсекать", чтобы оставаться в этом диапазоне - непонятно, там хитрая структура файла (сам себе дерево со множеством связанных). Вот и получается, что для надёжности закладываю мало, и выигрыш, в общем случае, невелик. Проще положиться на скорость винта, потерять лишний час на процессе часов в пять, чем на пятом часу обнаружить, что зашкалил за гиг и всё зависло...

Файл это, примерно, миллион записей, каждая запись имеет от пяти до пятисот связанных. Всё это необходимо развернуть в линейный файл с парами "запись - связанная запись", дополнительно заполнив массу полей из справочных файлов и построив с пяток ключей. И это не самый сложный и не самый ресурсоёмкий из процессов

Это связано со скоростью построения деревьев в клиентском справочном приложении. Даже элементарное построение дерева из сгенерированного файла занимает несколько секунд, что напрягает пользователей. А если генерить из "исходного неразвёрнутого" файла, будет секунд пятнадцать (от этого пользователи недовольно взвоют)

[Игорь Столяров]

А выигрыша, практически, и не получается.

Я понимаю, зачем Вы используете Logout() с БД TPS ... но транзации - это всё-таки про целостность данных.

Когда речь идёт об адресации памяти в x32 - то это цельный кусок. Например динамическая строка до 4 GByte.
А на списочные структры это не накладывает каких-либо ограничений. Но то что ISAM драйвера "забиваются"
при тупой потокой записи - это факт. И отложенная запись через Logout() / Commit здесь не особо не спасают.

[Губин Игорь]

это всё-таки про целостность данных

У меня это про скорость, только скорость и ничего кроме скорости. Использование LogOut значительно ускоряло процесс при работе с HDD

[finsoftrz]

У меня по замерам была оптимальная скорость, если разделить logout на блоки по 100 000 записей. Если не делить, то, начиная с какого-то момента, скорость деградировала.

Деревья это зло.

[Игорь Столяров]

если разделить logout на блоки по 100 000 записей

Ну, гипотетически, можно замерить время выполнения первых 10 000 записей и далее контролировать по Clock() этот показатель.
Если он проваливается - делаем Commit + Logout. У нас так для текста делается, только Flush + Stream.

[Губин Игорь]

Ну, гипотетически, можно замерить время выполнения первых 10 000 записей и далее контролировать по Clock() этот показатель.

Именно, что гипотетически... Слишком скользкая идея для ситуации, когда вдруг может начать грузить память не обрабатывая данных...
Ну его нафиг так рисковать... Слишком долгий процесс. А таких несколько подряд и, если оборвётся один - все заново запускать...

[finsoftrz]

Может, обсудить, как лучше юзать юникод и 64 бита в приложениях на кларионе без участия SV?
По юникоду разные решения уже есть. А по 64 битам недавно озвучивался вариант вызова 64 битных утилит и скриптовых движков, используя win api.

[Игорь Столяров]

По юникоду разные решения уже есть

Скажите честно, у Вас много программ, где нужно в одном окне (списке) показывать текст в разных национальных кодировках ?
Я вот даже затрудняюсь ответить куда бы это можно было прикрутить (у нас есть пользователи в СНГ, Украине, ОАЭ ...)

А по 64 битам недавно озвучивался вариант вызова 64 битных утилит

Тот же вопрос. Я сталкивался с данными в INT64 только в [плохое слово] API OZON.
Где вообще всё сделано на INT64, даже флаги. Не потому что нужно, а потому что можем.
Ну сделали через GROUP и DECIMAL ... Или Вы про запуск бесконечных внешних EXE при работе программы ?

[Губин Игорь]

По юникоду разные решения уже есть.

И они решают ввод/вывод в экранных формах и на печать?! Чтение/запись юникода в файлы, в рамках своих потребностей, я уже давно делаю без проблем...

[Губин Игорь]

Скажите честно, у Вас много программ, где нужно в одном окне (списке) показывать текст в разных национальных кодировках ?

У меня во всех. Проблем отображения национальных кодировок в заголовках окон меня заботит очень давно. Внутри окон всё решил, спасибо CHARSET:

[Игорь Столяров]

кодировок в заголовках окон

Это другая история ... В принципе, я тоже сталкиваюсь с этим в заголовках PDF файлов.
Ну просто пишем всё на английском. Не бест решение, но работает корректно.

[kreator]

Есть база комплектующих на Постгре. Комплектующие со всего мира. Там есть поля для отображения информации на родных языках, где производят эти комплектующие. У себя в программе можем их отобразить через известное место. А записать вообще непонятно как.