A ListObject
не имеет свойства Offset
; Range
делает.
Возможно, используйте DataBodyRange
, который
возвращает объект
blockquote>Range
, представляющий диапазон значений, исключая строку заголовка, в таблице.Пример, который записывает в строку
x
и столбецy
таблицы (без использованияOffset
):Sub TestMyTable() Dim tbl As ListObject Set tbl = Sheets("Workouts").ListObjects("tbl_Workouts") Dim x As Long, y As Long x = 1 y = 1 tbl.DataBodyRange(x, y).Value = 1 ' or tbl.DataBodyRange.Cells(x, y) End Sub
Я нашел при реализации оптимизации компилятора учебника, что некоторые из них имели тенденцию инвертировать улучшения, сделанные другой оптимизацией. Это повлекло за собой большую работу, пытающуюся найти правильный баланс между ними.
Таким образом, действительно нет хорошего ответа на Ваш вопрос. Все - компромисс. Много оптимизации работают хорошо над одним типом кода, но являются pessimizations для других типов. Это похоже на разработку дома - при создании кухни большего размера кладовая становится меньшего размера.
Реальная работа в создании оптимизатора испытывает различные комбинации, сравнивая результатов, и, как шеф-повар, выбирая правильное соединение компонентов.
Исторически, существует "алгоритмическая" оптимизация, из которой код должен извлечь выгоду в большинстве случаев, как развертывание цикла (и разработчики компилятора должны реализовать ту "зарегистрированную" и "протестированную" оптимизацию сначала).
Затем существуют типы оптимизации, которая могла извлечь выгоду из типа используемого процессора (как использование инструкций SIMD относительно современных центральных процессоров).
Посмотрите Оптимизацию Компилятора на Википедию для ссылки.
Наконец, различный тип оптимизации мог быть протестирован, представив код или делая точную синхронизацию повторного выполнения.
Язык в щеке:
Более серьезно это зависит от архитектуры и целей Вашего компилятора. Вот опыт одного человека...
Пойдите для "больших выплат":
Пойдите для остающегося "низко висящего плода":
Продолжайте сравнивать.
Посмотрите на вывод; зафиксируйте что-либо, что выглядит глупым.
Обычно имеет место, что объединение оптимизации или даже повторение оптимизационных проходов, являются более эффективными, чем Вы могли бы ожидать. Преимущество является больше, чем сумма частей.
Можно найти, что введение одной оптимизации может требовать другого. Например, SSA с выделением регистра Briggs-Chaitin действительно извлекает выгоду из распространения копии.
Я не разработчик компилятора, но почему не только инкрементно оптимизируют части Вашего кода, представляя все время?
Моя схема оптимизации обычно идет:
1) удостоверьтесь, что программа работает
2) найдите, что что-то оптимизирует
3) оптимизируйте его
4) сравните результаты испытаний с тем, что прибыло из 1; если они отличаются, то оптимизация является на самом деле повреждающимся изменением.
5) сравните различие в синхронизации
Инкрементно, я получу его быстрее.
Я выбираю который части сфокусироваться на при помощи профилировщика. Я не уверен, какую дополнительную информацию Вы соберете путем выяснения у разработчиков компилятора.
Стоит отметить, что во многих случаях, разработчики компилятора НЕ проведут много времени, если таковые имеются, при обеспечении, что их библиотеки оптимизированы. Сравнительные тесты имеют тенденцию преуменьшать роль или даже игнорировать различия библиотеки, по-видимому, потому что можно просто пользоваться различными библиотеками. Например, алгоритмы перестановки в GCC асимптотически* менее эффективны, чем они могли быть при попытке переставить сложные данные. Это касается неправильного создания глубоких копий во время вызовов для свопинга функций. Это будет, вероятно, исправлено в большинстве компиляторов с введением rvalue ссылок (часть C++ 0x стандарт). Перезапись STL, чтобы быть намного быстрее удивительно легка.
*Это предполагает, что размер переставляемого класса является переменным. Например, перестановка вектора векторов ints замедлилась бы, если бы векторы ints были больше.
Это действительно зависит от того, что Вы компилируете. Существует, была довольно хорошая дискуссия об этом в списке рассылки LLVM недавно, это, конечно, несколько характерно для оптимизаторов, которые они имеют в наличии. Они используют сокращения для большого количества их оптимизационных проходов, если не знакомый с каким-либо из акронимов, которые они бросают вокруг Вас, можно посмотреть на их страницу передач для документации. В конечном счете можно провести годы, читая научные газеты на этом предмете.
Это - одна из тех тем где научные работы (ACM, возможно?) может быть один из лучших источников актуальной информации. Лучшая вещь сделать, если Вы действительно хотите знать, могла бы состоять в том, чтобы создать некоторый код в неоптимизированной форме и некоторых в форме, которую оптимизация примет (развернутые циклы, и т.д.) и на самом деле выяснит, где усиления, вероятно, будут использовать компилятор с выключенной оптимизацией.
Тот, который может дать большие ускорения, но редко делается, должен вставить инструкции по упреждающей выборке памяти. Прием должен выяснить, какую память программа будет желать достаточно далеко заранее, никогда не попросить неправильную память и никогда не переполнять D-кэша.