Как известно, если чего-то не хватает, можно сделать свою dll. Можно даже добавить функцию для определения длины строки!

Но всё это не очень просто для простых смертных, как ни крути.

Понижаем порог входа в разработку ИРБИС64, коллеги.

Язык Python в общем-то в представлении не нуждается.

Не требуется компиляции, простой, ясный синтаксис, легко начать, приятно углубляться.

Для начала работы нужно на сервер установить python, в ИРБИС64 положить библиотеку pyrun.dll, добавить pythonNN.dll, и что-нибудь на языке python.

Пример example.py:

def echo(input_str):
    return input_str

def hello(input_str):
    return 'hello world!'

Соответственно, примеры форматов:

&uf('+8pyrun,StrPyStr,example|echo|',v200^A)

&uf('+8pyrun,StrPyStr,example|hello|')

Благодаря возможностям языка и возможности вызвать любую функцию - можно делать всё.

Кидать веб-запросы, создавать файлы, удалять файлы, удалить все базы, отформатировать жесткий диск. Будьте благоразумны.

Благодаря простому подключению python функций и прокидыванию данных, сама библиотека работает прозрачно и пока идей о дополнительных функциях нет. так что в библиотеке ровно одна функция - StrByStr.

Ссылка на проект:
[github.com]

Качнуть:
[github.com]

Python хорош, но далек от звания самого производительного. Исследование данного вопроса:

Запускаем серверную глобальную корректировку. ИРБИС сам сделает N запусков, остаётся только собрать результаты и сравнить. Учитывая привязку к железу, важны порядки и относительность.



1. Empty
Глобальная корректировка с IF False FI, корректировка записи не производится. Т.е. фактически простой перебор записей, пол миллисекунды - идеал, быстрее не будет.

2. Native/C++
Глобальная, штатная, echo корректировка.

Записать в поле 920 содержимое поля 920. Полторы миллисекунды, на чтение-запись-сохранение. Учитывая предыдущие затраты на обход, самая операция занимает около 1 мс.

Что интересно, dll с echo функций не даёт накладных расходов и занимает столько же времени (соответственно - C-функции - это неудобно - но эффективно)

3. Py_Initalaize
В прототипе библиотеки происходит python-инициализация-деинициализация. И больше ничего. И это уже даёт значительное замедление. Грубо говоря - в 80 раз.

4. Py import
После инициализации добавлен функционал по поиску модуля-функции. (Считай + файловая операция)

Итак, 100 мс, что уже в 100 раз медленнее штатных механизмов. Однако, значительное замедление было на предыдущем шаге. Т.е. сам импорт порядка 20 мс.

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

Выводы

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

Если же разработчики ИРБИС64 внедрят подключение к Python.dll на уровне сервера, замедление сократится конечно - но будет всё равно неприятным для простых обработок.

Но даже сейчас 80 мс. - приемлемый лаг для одиночных операций.

Категорически показан для ФЛК записи после редактирования, отлично подойдёт для оперативных режимов, позволит делать мощные штуки в дополнительных кнопках интерфейсов.

Непосредственные примеры использования ещё впереди.

Питонисты всех стран, питонируйте.



Редактировано 1 раз. Последний раз 25.03.2022 22:07 пользователем levaleva.