Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
С другой стороны, я понимаю ваше беспокойство, и в чем-то даже согласен - сейчас об оптимизации думают слишком поздно, и иногда бывает уже слишком тяжело что-то улучшать. Мне на самом деле интересны ваши сообщения, так как, по-моему, на уровне операций и оптимизации операций вы действительно знаете больше меня. И если у вас есть какие-то исследования на эту тему, мне было бы интересно их прочитать. Но с чем я не согласен, так это вашим подходом - "оптимизация во всем", причем похоже это что-то из разряда внутреннего культа, а не целесообразности. Да, я понимаю, что операция косвенности немножко медленнее, чем прямое обращение, но в подавляющем большинстве случаем этим можно пренебречь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2010, 15:16 |
|
||
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
Блок А.Н. - в тех задачах, где я разбирался (обработать миллионы строк), большая часть времени идет на доступ к данным, а не на их обработку. И именно доступ и выборку данных имеет большой смысл оптимизировать. Простите, Вы серьезно собираетесь говорить об "оптимизации доступа к данным", пользуясь объектами и псевдо-SQL? Вы хоть раз видели, как выглядит код в .T? Сколько там Xecute, сколько там @ и насколько многоуровневые там вложения? Блок А.Н. Ваш подход имеет смысл только в одном случае - когда нужно сделать десятки миллионов операций с небольшим набором данных. В этом случае да, нужно думать о оптимизации элементарных операций. Но что-то мне кажется, что такая задача не является типичной для СУБД, и я бы даже подумал, чтобы такие задачи решать не в байткоде, как в каше, а, например, в C++. Извините, но Вы не правы. Не думаю, что чтение данных в Вашем случае НАСТОЛЬКО затратно, что Вам уже просто наплевать на последующее быстро/медленно-действие. А насчет C++ и прочих ассемблеров мы уже проходили, замучаетесь гонять данные, быстрее все-равно не получится. P.S. Насчет сравнений... все относительно конечно. Раньше задача работала в среднем 5-10 минут и это было нормально. Сейчас она работает 10-15 секунд и мне говорят "Эээ, Сергей Геннадьевич, что-то тормозит ваша задачка". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2010, 10:01 |
|
||
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.С другой стороны, я понимаю ваше беспокойство, и в чем-то даже согласен - сейчас об оптимизации думают слишком поздно, и иногда бывает уже слишком тяжело что-то улучшать. Нет, сейчас об оптимизации программного продукта не думают вообще. Так принято. Так будет и дальше. Проще оптимизировать технику. Блок А.Н. Мне на самом деле интересны ваши сообщения, так как, по-моему, на уровне операций и оптимизации операций вы действительно знаете больше меня. И если у вас есть какие-то исследования на эту тему, мне было бы интересно их прочитать. Спасибо за доброе слово. Но увы, я простой прикладник, статей не писал никогда. Вот разве что тут иногда взрываюсь, уж простите. Блок А.Н. Но с чем я не согласен, так это вашим подходом - "оптимизация во всем", причем похоже это что-то из разряда внутреннего культа, а не целесообразности. Да, я понимаю, что операция косвенности немножко медленнее, чем прямое обращение, но в подавляющем большинстве случаем этим можно пренебречь. И опять нет. Для меня это просто "правила хорошего тона". И пренебречь ими следует только тогда, когда речь идет об интерактивности. В моменты обработки данных такие пренебрежения недопустимы. Потому как они имеют свойство умножаться. Впрочем, как уже говорилось, это сугубо мое личное мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2010, 10:09 |
|
||
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
"Вы хоть раз видели, как выглядит код в .T? " Сергей Геннадьевич, пожалуйста, поделитесь знанием или ссылками хотя бы. P.S. Требования к скорости разработки будут только возрастать, а люди являются самой затратной и проблемной частью :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2010, 12:55 |
|
||
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov Простите, Вы серьезно собираетесь говорить об "оптимизации доступа к данным", пользуясь объектами и псевдо-SQL? Вы хоть раз видели, как выглядит код в .T? Сколько там Xecute, сколько там @ и насколько многоуровневые там вложения? ... Не думаю, что чтение данных в Вашем случае НАСТОЛЬКО затратно, что Вам уже просто наплевать на последующее быстро/медленно-действие. [quot Sergei Obrastsov] А насчет C++ и прочих ассемблеров мы уже проходили, замучаетесь гонять данные, быстрее все-равно не получится. От объектов в массовой обработке данных категорически отказались, а SQL вполне используем. Да, я видел int-код, и когда каше еще не умела показывать план запросов, по нему разбирался, что именно происходит (брр). Так вот, несмотря на свою страшность, int-код sql-запроса вполне конкурирует с прямым доступом по скорости, более того, иногда немного быстрее (программист тоже человек). Правда тут надо смотреть внимательно, не все запросы каше делает оптимально, очень плохо делаются вложенные запросы, некоторые агрегатные, типа найти минимум по индексированному полю - тут надо смотреть индивидуально. И да, затратно именно обращение к данным. У нас так как объем данных сотни Гб, а кэш 8 гб сделали совсем недавно, а до этого было 2Гб - данные кэшируются слабо. И разработка на прямом доступе там, где это не требуется - для меня не является хорошим тоном, так как такую программу сложнее понять, в ней легче сделать ошибки, она не учитывает новые индексы и изменившуюся структуру класса, ее сложнее дорабатывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2010, 14:17 |
|
||
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Так вот, несмотря на свою страшность, int-код sql-запроса вполне конкурирует с прямым доступом по скорости, более того, иногда немного быстрее (программист тоже человек). Это Вы так пошутили. Я понимаю, смешно. Блок А.Н. Правда тут надо смотреть внимательно, не все запросы каше делает оптимально, очень плохо делаются вложенные запросы, некоторые агрегатные, типа найти минимум по индексированному полю - тут надо смотреть индивидуально. Извините, ну никогда стандартизированный движок, тратящий время еще и на осмысливание запроса, не будет быстрее прямого доступа. Это Вы уж загнули. Блок А.Н. И да, затратно именно обращение к данным. У нас так как объем данных сотни Гб, а кэш 8 гб сделали совсем недавно, а до этого было 2Гб - данные кэшируются слабо. Общий объем данных далеко не критерий. Вопрос в операционном объеме. Я слабо себе представляю, для чего может понадобиться такой гигантский кэш. Разве что тысячи пользователей делают гигантские выборки. Блок А.Н. И разработка на прямом доступе там, где это не требуется - для меня не является хорошим тоном, так как такую программу сложнее понять, в ней легче сделать ошибки, она не учитывает новые индексы и изменившуюся структуру класса, ее сложнее дорабатывать. Давайте определимся, мы говорим о скорости работы программы или о скорости ее понимания? Что толку от идеально понятной программы, если она еле ползает? И зачем кому-то ковырять программу, если она и так работает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2010, 06:14 |
|
||
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
Стандартный движек даже в динамик sql думает один раз, а потом работает, я так понимаю. Тем более в embed-sql. У нас около полумиллиона договоров пересчитывают пеню, причем пеня пересчитывает за весь период (так как ставка рефинансиования может поменяться задним числом), на каждом договоре могут быть сотни строк в 4х таблицах, причем эти таблицы перевезаны крест-накрест. Всего объем задействованных данных ориентировочно 150-200Гб. Это только один из запускаемых расчетов ночью. Даже 8 Гб кэша это мизер для таких задач. Изменить структуру данных пока не представляется возможным из-за большого количества программ. Непосредственно рядом сидит команда разработчиков, которая делает доработки по требованию заказчика, причем частично меняя старый функционал и частично создавая новый. Обновления делаются каждый день, так что вопрос понимаемости старых программ и возможности их доработки стоит очень остро. Если у вас задачи математического плана - поднять 1 гб данных в 2гб кэш и пересчитать, причем алгоритмы трудоемкие, то у вас будут другие подходы к оптимизации, это понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2010, 06:43 |
|
||
|
Программное чтение / запись в глобал
|
|||
|---|---|---|---|
|
#18+
doublefint"Вы хоть раз видели, как выглядит код в .T? " Сергей Геннадьевич, пожалуйста, поделитесь знанием или ссылками хотя бы. Да пожалуйста, наслаждайтесь. Cinema.Film.T1 из SAMPLES: Код: 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. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. Я прошу прощения, не могу вспомнить в каких структурах видел Xecute. Буду ковырять дальше. doublefint P.S. Требования к скорости разработки будут только возрастать, а люди являются самой затратной и проблемной частью :( Судя по тому, что я наблюдаю, скорость разработки как раз падает. А что люди? Когда они видят, что на всех уровнях к качеству ПО относятся все хуже, они начинают делать соответствующие выводы. Отсюда мы имеем то, что есть: разработка идет медленнее, программы работают медленнее, объемы хранимых данных бессмысленно растут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2010, 07:19 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=36856796&tid=1557957]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
61ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 212ms |
| total: | 393ms |

| 0 / 0 |
