Lotus Script: взгляд изнутри

[TIA]

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

Просто юз. Добавим вызов:

...
Добавил ешё формульную акцию - 7,9кб
<--продолжим-->
Добавил в акцию 1 вызов метода f1 - 8,7кб
Добавил в акцию 1 вызов метода f2 - 8,8кб
Добавил в акцию 1 вызов метода f2 ещё раз - 8,8кб (увеличился на ~10б)

Т.о. накладных расходов на 1 вызов (а больше и не надо) - 900 б . Далее тоже самое, что будет и в агенте.
Размер пустого агента (без Use) - 3,5кб.

Стоило же снести весь код экшенов в агенты которые запускаются по собаке @Command([ToolsRunMacro];"ХХХ") размер под формы удалось уменьшить сразу на треть(более чем на 100К за 3 экшена)

А на сколько у вас увеличился размер подгружаемого кода, с учётом, что наплодили агентов, а каждый пустой агент 3,5кб?

 

[ToxaRat]

А на сколько у вас увеличился размер подгружаемого кода, с учётом, что наплодили агентов, а каждый пустой агент 3,5кб?

а тут нужно подходить с другой стороны
зайдя в документ не факт что вы нажмете на ВСЕ экшены, а нажимая на экшен в котором лишь собака запускающая агент, вы четко инициируете подрузку только этого кода и все другие экшены в холостую не подгружаются и не тянут на себя вес подформы

 

[TIA]

зайдя в документ не факт что вы нажмете на ВСЕ экшены, а нажимая на экшен в котором лишь собака запускающая агент, вы четко инициируете подрузку только этого кода и все другие экшены в холостую не подгружаются и не тянут на себя вес подформы

Я уже говорил, что подгрузка библиотек заюзанных в акциях происходит тоже только при нажатии акции. Другие библиотеки, заюзанные в других акциях при этом не подгружаются. В других элементах формы (не акциях) можно использовать динамическую подгрузку через Execute

 

[ToxaRat]

стокнулся с еще одной забавной ситуацией, она конечно более специфическая, но разница в 7 раз
итак имеем два варианта кода занимающихся преобразованием потока в BASE64
Первый через стринговую переменную - cBASE64

l = s(i) * 65536 + s(i+1) * 256 + s(i+2)
cBASE64 = cBASE64 & b64(l \ 262144) & b64((l \ 4096) Mod 64) & b64((l \ 64) Mod 64) & b64(l Mod 64)

Второй через байтовый массив - vRezult

l = s(i) * 65536 + s(i+1) * 256 + s(i+2)
vRezult(i2) = byte64(l \ 262144)
vRezult(i2+1) = byte64((l \ 4096) Mod 64)
vRezult(i2+2) = byte64((l \ 64) Mod 64)
vRezult(i2+3) = byte64(l Mod 64)

Так вот второй вариант делает всё тоже самое в 7 раз быстрее, проверялось на буферах по 24573 байт
Для примера 1.5метровый файл первым методом преобразовывается 1:51 а вторым методом 0:16
я вот пытаюсь понять, это что-то если в стринг в конце докидывать по 4 символа то происходит постоянное переопределение всего стринга?

 

[TIA]

Так вот второй вариант делает всё тоже самое в 7 раз быстрее,

Да, известная проблема скорости работы LS со строками. Объясняется тем, что почти каждая операция конкатенации строк требует выделения нового буфера, копирования в него исходной строки и добавленной строки. Чем длиннее строка, тем дольше и сложнее выполняются первые два шага. Проблема общая для всех языков программирования, но такое ощущение, что в LS вообще не занимались оптимизацией.

 

[lmike]

подтверждая слова TIA могу отметить, что в java есть StringBuffer
именно по этой причине

Ссылка скрыта от гостей

и раз зашла речь о Base64 -

Ссылка скрыта от гостей

 

[ToxaRat]

Да, известная проблема скорости работы LS со строками. Объясняется тем, что почти каждая операция конкатенации строк требует выделения нового буфера, копирования в него исходной строки и добавленной строки.

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

 

[lmike]

ToxaRat
java и не надо "думать"

 

[Klido]

java

как раз НАДО думать

 

[lmike]

Klido
а о чём?

 

[TIA]

ToxaRat
Кстати, в нотес есть штатная реализация base64 через строки в "lsxsd.lss":
Function notesStreamToBase64 (ns As NotesStream) As String
Function base64ToNotesStream (b64String As String) As NotesStream

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

 

[Klido]

Klido
а о чём?

ну, например, вот - какой квикфикс применить

реально - джава это хорошо, только сначала надо порвать себе моск потом, понятно, уже всё чудесно...

 

[ToxaRat]

Кстати, в нотес есть штатная реализация base64 через строки в "lsxsd.lss":
Function notesStreamToBase64 (ns As NotesStream) As String
Function base64ToNotesStream (b64String As String) As NotesStream

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

в 6.5.6 не нашел, и как я понимаю они только с 7-ки

 

[lmike]

ToxaRat
Кстати, в нотес есть штатная реализация base64 через строки в "lsxsd.lss":
Function notesStreamToBase64 (ns As NotesStream) As String
Function base64ToNotesStream (b64String As String) As NotesStream

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

мне там цикл понра

	' Output lines are limited to 76 chars, and because every
' three input bytes produce 4 output chars we process
' up to 57 input bytes at a time. (57 = 76 / 4 * 3)
Dim inLength As Long
inLength = nsLength
If inLength > 57 Then inLength = 57
nsLength = nsLength - inLength

и в его теле : notesStreamToBase64 = notesStreamToBase64 & outString & Chr$(13) & Chr$(10)
при том что выше обсуждалась контектация в ЛС

так-чта ToxaRat не много потерял

 

[TIA]

при том что выше обсуждалась контектация в ЛС

эту бяку я имел в виду

base64 через строки

 

[nvyush]

Yakov
Интересно узнать, оптимизирует ли компилятор вызов функции Chr$() с аргументом-константой. Почему-то IBMеры не включили эту функцию в список разрешённых для инициализации констант, т.е. так написать нельзя:
Const CHR_10 = Chr$(10)
а так можно :whoareyou?::
Const CHR_10 = {
}

 

[Yakov]

nvy, читайте внимательно справку:

Returns the character represented by a value interpreted as a locale-sensitive character code.
Syntax
Chr[$] ( numExpr )
Elements
numExpr
A numeric expression of data type Long in the range 0-255. If LotusScript is running on a native ASCII platform, the value is interpreted as a character code in the platform-native character set. If LotusScript is running on an EBCDIC platform, the value is interpreted as the character code for the ASCII equivalent in the platform's current locale. In either case, only single-byte ASCII values are valid.
Return value
Chr returns the character corresponding to the value of numExpr.
Chr returns the ANSI platform-specific character corresponding to the value of numExpr.
Chr returns a Variant of DataType 8 (String). Chr$ returns a String.

Результат работы функции зависит от платформы, на которой выполняется код.

 

[nvyush]

А для chr$(9), chr$(10) результат тоже зависит от платформы? Меня в первую очередь интересовали служебные символы. В частности, если компилятор оптимизирует строку Msgbox "строка1" + chr$(10) + "строка2" и вместо chr$(10) подставляет значение вызова данной функции, то нормально, а если он вызывает функцию chr$, то разумнее заменить константой. Я понимаю, что это копейки, но всё же байт килобайт бережёт.

 

[Akupaka]

но всё же байт килобайт бережёт

пиши тогда:

Msgbox |строка1
строка2|

 

[nvyush]

пиши тогда:

Msgbox |строка1
строка2|

Не, мне интереснее писать так:

Const CHR_10 = {
}
Msgbox "строка1" + CHR_10 + "строка2"

Строки могут быть и переменными и результатами вызова функций. Упаришься громоздить конструкции вида:

Msgbox str1 + |
| + str2

да и нечитабельные они какие-то.