|
|
|
оптимизация C UDR
|
|||
|---|---|---|---|
|
#18+
Привет! Роясь на сайте IBMеров, нашел статью посвященную оптимизации работы с памятью C-шной UDR при возврате double precision. Чтобы не пересказывать своими словами умных людей ;) вот выдержка касательно сути проблемы: Код: 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. 31. 32. 33. 34. 35. 36. 37. 38. автор The UDR fires once for each row in a query. So if a query scans a thousand rows, the code in Good Code #1 executes a thousand times....and calls mi_alloc() a thousand times, which starts sounding expensive. Consider a table with 40 million rows, and the allocation costs start sounding prohibitive. Теперь суть вопроса: У меня вопрос по возврату mi_lvarchar * Одна из моих процедур возвращает строку всегда 64 байта длиной, поэтому сама собой напрашивается оптимизация - возвращаемый буфер всегда будет правильной длины. Хочется его зареюзать, как в приведенном примере. У меня буфер для возвращаемого значение получается так: mi_lvarchar *rc; rc=mi_new_var(64); mi_set_varlen(rc, 64); ...туда копируется результат вычислений... return rc; Пытался наобум повторить метод как mi_new_var(64, PER_COMMAND) - компилятор ругается. Если я пытаюсь сохранять сам указатель rc то при втором вычислении функции запрос падает по ексцепшену. Пытался играться с mi_switch_mem_duration() - не помогло, все равно падает. Вопрос: можно ли как-то этот буфер реюзать, чтобы не аллокировать по 64 байта на каждую строку выполнения запроса ? Спасибо за умные мысли :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2006, 02:02 |
|
||
|
оптимизация C UDR
|
|||
|---|---|---|---|
|
#18+
falcon111... Вопрос: можно ли как-то этот буфер реюзать, чтобы не аллокировать по 64 байта на каждую строку выполнения запроса ? Спасибо за умные мысли :-) Похоже, что умные мысли будут только на специализированных форумах по С, но не на этом, посвященном Informix... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 16:55 |
|
||
|
оптимизация C UDR
|
|||
|---|---|---|---|
|
#18+
Похоже, что на С-шных никто не знает, что такое информикс, а на информиксовых - никто не знает, что такое С ;-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2006, 21:45 |
|
||
|
оптимизация C UDR
|
|||
|---|---|---|---|
|
#18+
А ты автору статьи напиши может ответит. Они любят иногда потрепаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2006, 22:01 |
|
||
|
оптимизация C UDR
|
|||
|---|---|---|---|
|
#18+
falcon111 Код: plaintext 1. 2. 3. 4. mi_new_var(64, PER_COMMAND) - компилятор ругается. И правильно делает. new_var сам по себе аллоцирует память, и параметр у него один. Если надо аллоцировать память другим способом, то именно этот способ и нужно копировать, например: rc=(mi_lvarchar *)mi_dalloc(тут поставить размер,PER_COMMAND); Размер, конечно, лучше не напрямую кодировать, а через 64*sizeof(mi_char) или как-то так (увы, лично я в C ориентируюсь примерно как во французском языке: кое-что знаю, но ничего конкретно). Умные мысли по всему этому поводу лежат внутри $INFORMIXDIR/incl/public/*.h Эти мысли надо показывать C-шным программистам, чтобы они поняли, что такое информикс. По крайней мере, когда мне понадобилась UDR для интерфейса к crypt(), я так и поступил. Мне помогли, правда, сказав "нам лень и тут всё неоптимально, зато работать будет". Поскольку crypt сам по себе от оптимума обязан быть далёк, я и не парюсь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 17:42 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=33767549&tid=1608645]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
41ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 355ms |

| 0 / 0 |
