|
|
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
Есть разница в производительности: 1) int myInt = a.b.c.d.e.f.g.......zzz999.BigIntMassive[99999]; 2) int myInt = a.BigIntMassive[99999]; ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 11:44 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
Да, и эта строка в цикле - считываю с массива данные по одной штучке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 11:44 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
Вообще, хотел написать так (тоже в цикле) 1) int myInt = a.b.BigIntMassive[99999]; 2) int myInt = a.BigIntMassive[99999]; но потом подумал, что первый вариант будет нагляднее. Ну, а в этом варианте есть разница в производительности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 11:45 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
Или компилятор на этапе компиляции эту абракадабру разбирает и сразу берёт значение по адресу, который в массиве указан (с учётом сдвига)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 11:46 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
user73201) int myInt = a.b.BigIntMassive[99999]; 2) int myInt = a.BigIntMassive[99999]; первый вариант потенциально будет медленнее работать. Адрес вложенного поля нельзя рассчитать на этапе компиляции. JIT-компилятор может выполнить оптимизацию сохранив a.b.BigIntMassive в отдельную переменную. Такой гарантии никто дать не может, так что лучше дать подсказку самостоятельно. Не понял почему ты считаешь первый вариант нагляднее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:33 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
bazileuser73201) int myInt = a.b.BigIntMassive[99999]; 2) int myInt = a.BigIntMassive[99999]; первый вариант потенциально будет медленнее работать. Адрес вложенного поля нельзя рассчитать на этапе компиляции. JIT-компилятор может выполнить оптимизацию сохранив a.b.BigIntMassive в отдельную переменную. Такой гарантии никто дать не может, так что лучше дать подсказку самостоятельно. Не понял почему ты считаешь первый вариант нагляднее. Потому что я думал, что компилятор (да хоть JIT), сделать так, чтобы можно было сразу адрес массива получать, а не последовательным "разыменованием указателей". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:43 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
bazileJIT-компилятор может выполнить оптимизацию сохранив a.b.BigIntMassive в отдельную переменную. Такой гарантии никто дать не может, так что лучше дать подсказку самостоятельно. А как дать подсказку? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:44 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
user7320, запиши ссылку "zzz999" в переменную и к ней обращайся. В VB.NET для этого есть With ... End With оператор, чтобы сократить длину ссылки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:53 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
Вместо Код: c# 1. написать Код: c# 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:56 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
И если конкретно, то не могли бы вы посоветовать, что делать в таком случае: У меня есть объект "Настройки", у которого поля - кучка этих самых настроек. Все поля имеют тип "Параметр", у которого есть поля: "Имя", "Значение", "Пояснение". Когда я делаю расчёт, я использую только поле "Значение" каждого параметра. И вот, один из параметров - большой (до миллиона элементов) массив данных. В расчёте я по нескольку раз запускаю цикл, который проходит по этому массиву, но при этом обращение к массиву идёт как Настройки.ПараметрМассив.Значение[индекс]. Что лучше сделать: придумать новый тип - например, "НастройкиБезПояснений" - где все параметры будут сразу иметь только значение, или достаточно для одного массива завести отдельную переменную в функции расчёта, ссылающуюся на этот массив? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:56 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
bazile Код: c# 1. За пределами цикла причем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:57 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
А, понятно. То, что выше - это как вы и предложили. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2013, 12:57 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
Ну ладно, с путями во вложенных объектах понятно. А как быть с путями во вложенных пространствах имён? На их разборку тоже время тратится и лучше не вкладывать пространства имён без особой надобности? Ну, т. е. тот же самый пример, что выше, только вложенность в пространства имён, а не в типы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2013, 11:40 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
Я имею ввиду, что тратится время во время выполнения программы, а не во время компиляции (только не JIT - если JIT, то это то же, что во время выполнения, как я понимаю). Если во время компиляции только (но не JIT), то пусть тратится. Главное, что мне удобно сделать кучу вложений для поддержки и упорядочивания кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2013, 11:42 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
У меня такое чувство, что вы маетесь дурью. Во первых, вложенность неймспейсов влияния на скорость работы программ, как и их компиляцию, не оказывает Во-вторых, даже работа с кучей вложенных друг в друга объектов будет очень быстрой Если у вас "оптимизаторский" зуд (хотя общеизвестно, что преждевеременная оптимизация редко когда бывает полезна), смотрите и оптимизируйте алгоритмы, параллельте задачи, уменьшайте количество обращений к внешним ресурсам и дискам. Это многократно больше даст выйгрыша во всех аспектах. Например, задача поиска простых чисел. В лоб решается очень тяжелым алгоритмом. Зато придумали несколько других, гораздо быстрее ( http://ru.wikipedia.org/wiki/%D0%E5%F8%E5%F2%EE_%DD%F0%E0%F2%EE%F1%F4%E5%ED%E0) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2013, 12:04 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
авторВо-вторых, даже работа с кучей вложенных друг в друга объектов будет очень быстрой Я выше написал, что работа будет в цикле. Коллекция находится на третьем-четвёртом уровне вложенности. В цикле миллион итераций, на каждой из которых по нескольку раз может быть обращение к элементу коллекции. Алгоритм работает три секунды на моей машине. Если добавится хотя бы полсекудны времени только из-за вложенностей объектов, это будет, конечно, некритично, но всё равно как-то неприемлемо. Это пока алгоритм работает с данными, полученными после эксперимента. Далее, планируется перевести алгоритм на работу с данными, получаемыми прямо во время эксперимента. Там надо будет наверняка ещё уменьшить время работы с трёх секунд. И в этом случае увеличение времени работы алгоритма даже на полсекунды уже точно неприемлемо, т. к. можно не успеть до пуступления следующей порции данных. Кеширование тоже не поможет, потому что задача не закешировать данные, а вовремя отобразить результаты расчёта, т. к. по ним будет приниматься решение, продолжать эксперимент или прекратить его. Спасибо, что сказали, что вложенность пространств имён не влияет на производительность. Я так понимаю, что разобраться с этой вложенностью компилятор может во время компиляции, в отличии от вложенности объектов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2013, 12:24 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
user7320авторВо-вторых, даже работа с кучей вложенных друг в друга объектов будет очень быстрой Я выше написал, что работа будет в цикле. Коллекция находится на третьем-четвёртом уровне вложенности. В цикле миллион итераций, на каждой из которых по нескольку раз может быть обращение к элементу коллекции. Алгоритм работает три секунды на моей машине. Если добавится хотя бы полсекудны времени только из-за вложенностей объектов, это будет, конечно, некритично, но всё равно как-то неприемлемо. Это пока алгоритм работает с данными, полученными после эксперимента. Далее, планируется перевести алгоритм на работу с данными, получаемыми прямо во время эксперимента. Там надо будет наверняка ещё уменьшить время работы с трёх секунд. И в этом случае увеличение времени работы алгоритма даже на полсекунды уже точно неприемлемо, т. к. можно не успеть до пуступления следующей порции данных. Кеширование тоже не поможет, потому что задача не закешировать данные, а вовремя отобразить результаты расчёта, т. к. по ним будет приниматься решение, продолжать эксперимент или прекратить его. Спасибо, что сказали, что вложенность пространств имён не влияет на производительность. Я так понимаю, что разобраться с этой вложенностью компилятор может во время компиляции, в отличии от вложенности объектов? читать полностью ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2013, 12:32 |
|
||
|
Снова "оптимизирую"
|
|||
|---|---|---|---|
|
#18+
user7320Алгоритм работает три секунды на моей машине Что за алгоритм? Каждая итерация цикла использует данные предыдущей? ЗЫ Когда я говорил, что работа с вложенными объектами будет быстрой, я не имел ввиду, что не нужно её оптимизировать. Правильный совет дали в 13802328 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2013, 12:33 |
|
||
|
|
start [/forum/topic.php?fid=20&msg=38119326&tid=1405315]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 24ms |
| total: | 179ms |
| 0 / 0 |
