Какая часть стоит больше всего с точки зрения производительности в этом C-коде?

#c #performance #time-complexity #big-o

#c #Производительность #сложность по времени #big-o

Вопрос:

Я должен ответить на вопрос об относительно простом фрагменте C-кода. В приведенной ниже функции, что было бы самым дорогостоящим с точки зрения производительности или временной сложности? Я действительно понятия не имею, как ответить на это, потому что я чувствую, что это зависит от if-оператора. Также я не знаю, является ли сравнение дорогостоящим или нет, то же самое касается возврата, доступа к структуре и умножения.

Кстати, info_h это структура.

 RGBPixel* bm_get_pixel_at(
    unsigned int x,
    unsigned int y,
    RGBPixel *pixel_array )
{
    int index;
    int width_with_padding = info_h.width;
    if( x >= info_h.width || y >= info_h.height ){ return amp;blackPixel; }
    index = (info_h.height-1 - y) * width_with_padding   x;
    return pixel_array   index;
}
 

Редактировать:

Хорошо, вопрос, возможно, был немного странно сформулирован. Я должен добавить, что это всего лишь одна функция из многих в немного более сложной программе на c, над которой мы уже тридцать раз запускали скрипт oprofile. Затем скрипт возвращает результаты среднего времени выборки каждой процедуры oprofile. В этой таблице результатов эта функция заняла третье место по количеству выборок. Следовательно, следующий вопрос заключается в том, какая часть этой функции заставляет программу проводить в ней треть своего времени? Извините, если вначале было немного неясно

Комментарии:

1. Временная сложность равна O (1), нет цикла или рекурсии. Вероятно, эта функция все равно встроена.

2. В коде нет ничего особенного, если вы считаете, что ваша программа медленная, вам нужно профилировать ее производительность, чтобы вы могли найти узкое место.

3. «что» означает «какая часть этого»? В этом случае, пожалуйста, укажите детали, о которых идет речь.

4. Вероятно, наибольшая часть затрат — это накладные расходы на вызов функции. (если не встроено)

5. Что вы подразумеваете под «дорогостоящим»? Абсолютное время, затраченное на это? Самая неэффективная, то есть та часть, которую можно было бы оптимизировать больше всего? Это два разных вопроса.

Ответ №1:

Поскольку вы опустили остальную часть своей программы, все это превращается в догадки. То, что эта функция часто появляется в вашем результате профилирования, вероятно, связано с тем, что она вызывается внутри внутреннего цикла. Что делает эта функция (это довольно очевидно), так это то, что она возвращает ячейку памяти пикселя или, если запрошенный индекс находится за пределами массива пикселей, возвращает ячейку памяти фиктивного пикселя.

Если вы запускаете эту функцию внутри цикла, то проверка границ выполняется для каждой итерации, что, конечно, довольно избыточно. Это действительно низко висящий плод в отношении оптимизации: поставьте проверки границ перед циклом и убедитесь, что сам цикл не выходит за пределы границ:

 static inline
RGBPixel* bm_get_pixel_at_UNSAFE(
    unsigned int x,
    unsigned int y,
    RGBPixel *pixel_array )
{
    size_t const width_with_padding = info_h.width;
    size_t const index = ((size_t)info_h.height-1 - y) * width_with_padding   x;
    return amp;pixel_array[index];
}

RGBPixel* bm_get_pixel_at(
    unsigned int x,
    unsigned int y,
    RGBPixel *pixel_array )
{
    return ( x < info_h.width amp;amp; y < info_h.height ) ?
          bm_get_pixel_at_UNSAFE(x,y, pixel_array)
        : amp;blackPixel;
}

void foo(RGBPixel *pixel_array)
{
    /* iteration stays inside array bounds */
    for( unsigned int y = 0; y < info_h.height;   y )
    for( unsigned int x = 0; x < info_h.width;    x ){
        RGBPixel *px = bm_get_pixel_at_UNSAFE(x, y, pixel_array);
        /* ... */
    }
}
 

Комментарии:

1. Спасибо за ваш ответ. Вероятно, вы правы в том, почему это часто проявляется. Это тоже то, о чем я думал, но теперь, когда я набираю этот ответ, я только что понял ответ. Вопрос был немного странно сформулирован, поэтому я запутался и подумал, что должен был что-то идентифицировать в коде, но я думаю, что ответ «потому что он вызывается так много раз». Вот почему это часто проявляется, как вы сказали. У меня было неправильное мышление. Еще раз спасибо