Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
Обнаружил тут то ли баг то ли фичу - прошу подтвердить воспроизводится ли на ваших системах. Возможно придется оптимизировать код Описание на английском - делалось для WRC Try out the two method implementation below. The time elapsed is hardly dependent on use of concatenation method The classes are: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2009, 22:00 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
Предполагаю, что при первом вызове Concat() (шаг 3) выполняется запрос "User.A.Extent" и результат кэшируется в памяти, а при втором (шаг 4) используется этот самый результат из кэша. Попробуйте поменять местами вызовы шагов 3 и 4 - увидите аналогичную картину. Либо можете после каждого Concat-а очищать кэшированные запросы, тогда время отработки обоих вызовов будет одинаковым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2009, 08:09 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
Кэшированные запросы очищать смысла нет, так как это кэширование результата компиляции, а не кэширование объектного кода в памяти и тем более не кэширование результата. В данном случае происходит кэширование глобалов данных, для улучшения чистоты эксперимента либо после каждого запуска рестартовать каше, либо (что лучше), делать один пробный запуск без учета результатов, а потом уже считать время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2009, 09:04 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
Ребят, вы не может не поняли но тема в том, что программисты могут использовать такого рода конкатенацию (например часто приходится делать для ответа веб-сервиса) и этот неявный баг может спровоцировать колоссальное падение производительности ваших приложений - и фиг догадаешься на первый взгляд в чем дело. Производительность падает нелинейно при увеличении количества итераций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2009, 12:25 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
TurkПредполагаю, что при первом вызове Concat() (шаг 3) выполняется запрос "User.A.Extent" и результат кэшируется в памяти, а при втором (шаг 4) используется этот самый результат из кэша. Попробуйте поменять местами вызовы шагов 3 и 4 - увидите аналогичную картину. Либо можете после каждого Concat-а очищать кэшированные запросы, тогда время отработки обоих вызовов будет одинаковым. порядок не влияет - проверьте сами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2009, 12:26 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
Блок А.Н. , спасибо за поправки. Поторопился утром с ответом, не туда мысль пошла. Rus000 , проверить код именно в вашем варианте не могу - ограничение на длину строки в Cache 5.0 не дает это сделать. Пробовал чуть измененный вариант (с периодическим сохранением 32Кб блоков во временную глобаль), в этом случае разница между методами 1 и 2 была незначительной. Не пробовали прогонять оба метода через ^%MONLBL? Может причина кроется совсем в другом (хотя бы то же кэширование). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2009, 17:09 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
как-то темка уползла вниз, и никому не интересна, а в это время в гугл групс народ экспериментирует разница в времени исполнения - до 25 раз (!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2009, 22:22 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
У меня сервера, не поддерживает строки такого размера, а в цикле 2000 разница небольшая, процентов 25 (хотя тенденция заметна). Версия из новых, на чем тестируете вы? Или нужно что-то включить в настройках? Код: plaintext 1. 2. Операцию a=a_b можно теоретически выполнить двумя способами: либо к a добавить b, либо вычислить a_b и результат присвоить переменной a. Видимо в одном случае оптимизация происходит, в другом нет. Кстати, с монитором %SYS.MONLBL прогоняли тесты? Есть небольшой подозрение, что тормозит не в этом месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2009, 07:08 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
Rus000как-то темка уползла вниз, и никому не интересна, а в это время в гугл групс народ экспериментирует разница в времени исполнения - до 25 раз (!) У меня сомнений нет и не было в наличии проблемы. Гораздо интереснее, на каком этапе решение этого вопроса в WRC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2009, 08:39 |
|
||
|
Эксперимент с производительностью - проверьте
|
|||
|---|---|---|---|
|
#18+
ответ 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2009, 09:09 |
|
||
|
|

start [/forum/topic.php?fid=39&tid=1558507]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
175ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
| others: | 254ms |
| total: | 521ms |

| 0 / 0 |
