|
|
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Нагородил в коде что то вроде этого Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Те получается вроде как record в record. Вложенность получилась 3—4 уровня. И плюс все это храниться в Tlist<TZero> И в некоторых record тоже есть поля типа TList<> В результате по коду получается выборка по довольно длинному «пути» И закрадывается мысль, что это значительно влияет на производительность. Раньше с TList<> да и с record особо плотно не работал. Так вот хочу понять плохо ли такое использование record в плане производительности или все ж нормально? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2019, 02:21 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
И подозреваю, что подтормаживают именно итерации через items[i] по этим TList ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2019, 02:27 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
SwvИ закрадывается мысль, что это значительно влияет на производительность. Конечно. Каждый уровень вложенности будет замедлять раз в пять, если не больше. Поэтому об оптимизации надо думать еще до этапа проектирования. Нет ничего важнее оптимизации. А вместо вложенных рекордов используй вложенные массивы. С ними гораздо быстрее, чем без них. Особенно когда массивы используешь Items из TList<>. Хорошо, что ты сюда обратился. Здесь много известных специалистов-оптимизаторов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2019, 02:42 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
Фэйтл Эра, На последней фразе я аж поперхнулся (как раз завтракал)). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2019, 10:09 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
И сильна ли просадка? Или от нечего делать размышляешь? Первое правило оптимизации - не оптимизировать там, где это не требуется. Ну и слушать всяких "известных оптимизаторов" надо с бо-о-ольшим фильтром, иначе забьешь себе голову разной чухней типа "Каждый уровень вложенности будет замедлять раз в пять", так что на полезные соображения места не останется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2019, 11:00 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
Swv, Думаю, ваше решение значительно быстрее будет, чем если организовать в программе подобие реляционной БД и каждый раз искать в своем списка по ключу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2019, 11:34 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
P.S. тем более, у вас же везде будет доступ по известному (????) индексу, т.е. без поиска, и по ссылке. Куда же быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2019, 12:17 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
Кроик Семёнтем более, у вас же везде будет доступ по известному (????) индексу, т.е. без поиска, и по ссылке. Куда же быстрее? Так у него же .Items[], а это гарантированное копирование. В таких случаях нужно .List[] использовать, это прямой доступ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2019, 12:30 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
SwvЗдравствуйте. Нагородил в коде что то вроде этого Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Те получается вроде как record в record. Вложенность получилась 3—4 уровня. И плюс все это храниться в Tlist<TZero> И в некоторых record тоже есть поля типа TList<> В результате по коду получается выборка по довольно длинному «пути» И закрадывается мысль, что это значительно влияет на производительность. Это НИКАК не влияет на производительность Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2019, 15:21 |
|
||
|
Скорости record
|
|||
|---|---|---|---|
|
#18+
Premature optimization is the root of all evil (c) TC, реализуй как придумал, измерь производительность, не устроит - тогда будет о чем поговорить, а так сивка-бурка в безвоздушном пространстве ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2019, 18:03 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=39771454&tid=2039822]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
390ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 187ms |
| total: | 634ms |

| 0 / 0 |
