Обнаружил тут то ли баг то ли фичу - прошу подтвердить воспроизводится ли на ваших системах. Возможно придется оптимизировать код

Описание на английском - делалось для WRC


Try out the two method implementation below. The time elapsed is hardly dependent on use of
concatenation method

The classes are:


Steps to reproduce the behaviour:
1)do ##class(User.B).Populate(1000000)
2)do ##class(User.A).Populate(1000000)
3)do ##class(User.A).Concat(50000,1) ;run method 1 on 50000 objects
Method1 time elapsed=64.947529
4)do ##class(User.A).Concat(50000,2) ;run method 2 on 50000 objects
Method2 time elapsed=4.131934

We get the huge difference
in time elapsed!! Method1 over 8 time slower than Method2!

The more rows we count the more
difference in time elapsed we get.

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

Производительность падает нелинейно при увеличении количества итераций.

TurkПредполагаю, что при первом вызове Concat() (шаг 3) выполняется запрос "User.A.Extent" и результат кэшируется в памяти, а при втором (шаг 4) используется этот самый результат из кэша. Попробуйте поменять местами вызовы шагов 3 и 4 - увидите аналогичную картину. Либо можете после каждого Concat-а очищать кэшированные запросы, тогда время отработки обоих вызовов будет одинаковым.

порядок не влияет - проверьте сами

как-то темка уползла вниз, и никому не интересна, а в это время в гугл групс народ экспериментирует

разница в времени исполнения - до 25 раз (!)

ответ wrc:


set str = str_obj.Property

is much slower than

set var = obj.Property
set str = str_var

In the second case we do much less data movement of the increasingly long str. When we have
str=str_var we can just move the value of var to the end of the existing str (as long as it fits, which it
often will). But in the case of str=str_obj.Property we have to save the current value of str, do
the concatenation, then copy the entire concatenated string back into str.

So, it's not a bug that we able to optimize some cases. It's a feature.

We can not use the optimization when the expression on the right side of the concatenation is
something that might cause the value of str to change, because the optimization relies on being able to
use the existing str value.

Referencing an object property is not eligible because it may call a property Get method which
could change the value of str.