2

ビットマップ文字列をブラウザーに書き込み、それを画面に出力する関数があります。現在、これは各ピクセルの正しい値を個別に生成し、各ピクセルに対してwrite(int fd, char *Buff, int NumBytes)関数を 3 回使用することで機能します。

for (i = 0; i < IMAGE_HEIGHT; ++i)
{
    for (j = 0; j < IMAGE_WIDTH; ++j)
    {
        blue = blue();
        green = green();            
        red = red();

        write(soc, &blue, 1);
        write(soc, &green, 1);
        write(soc, &red, 1);
    }
}

私はコードを最適化したいと思っていましたが、 write() 関数を何度も呼び出すと確かに何か費用がかかると考えました。そのため、すべての値を文字配列に格納してから、書き込み関数を 1 回呼び出すというアイデアがありました。

write (soc, image_array, sizeof(image_array));

しかし、巨大な配列 (数十万/数百万の要素) で問題が発生するでしょうか? ヒープに割り当てるだけでこれを解決できますか? 愚かなことをしていないことを確認したかっただけです。

4

2 に答える 2

2

はい、複数の書き込みはあなたを傷つけます。

各バイトを個別に書き込んだり、全体を割り当てたりするのではなく、小さなバッファー（おそらく数KB）に書き込んで、いっぱいになるたびに書き込むことをお勧めします。これにより、メモリコストを抑えながらパフォーマンスを向上させることができます。

于 2012-04-09T02:50:48.907 に答える
1

Yes, in a typical case using dynamic allocation will cure (or at least relieve) the problem. On a typical system (e.g., Windows or Linux) the stack is limited to a few megabytes or so (somewhat variable, can be adjusted as link time, at least on Windows).

The space you have available on the free store tends to be limited primarily by available address space (or, in the case of a single large allocation, contiguous address space). Allocating up to a couple of gigabytes is fairly routine. On a 64-bit system, even larger allocations become fairly reasonable (in this case, typically limited primarily by available RAM, and how much slow-down you're willing to accept from using virtual memory).

于 2012-04-09T02:45:21.200 に答える