[過去ﾛｸﾞ]
ネットワークプログラミング相談室 Port4 (1001ﾚｽ)
ネットワークプログラミング相談室 Port4 http://mevius.5ch.net/test/read.cgi/tech/1034236536/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
230: 224 [sage] 02/10/31 15:13 Perlでは他の要因の方が大きいだろうけど、 Cの場合は同じように1バイトずつ読む場合でも、 fdopen()してストリームからgetc()とかで読むのと、 ファイルディスクリプタからrecv()で読むのでは バッファの関係で速度に雲泥の差がある。 移植性の問題もあるし、fdopen()しなくても 自前でバッファリングすれば問題ないが。 >>229 保証されてるかは知らんが、毎回FILE*のバッファが 一杯になるまで満たすような実装にはしないだろ。 http://mevius.5ch.net/test/read.cgi/tech/1034236536/230
234: デフォルトの名無しさん [sage] 02/10/31 18:16 >>230 どっちが性能いいの? http://mevius.5ch.net/test/read.cgi/tech/1034236536/234
243: 230 [sage] 02/10/31 23:57 >>234 ネタか？・・・まぁいいや。まじめに答えてあげるよ。 FILE *関係の関数、特にgetc()はマクロで実装されてる事が多いから、 バッファが空でなければ、そのチェック自身と一回の配列アクセスだけで 関数呼び出しすらなしに1バイトのデータを取得できる可能性が高い。 recv()の場合は、システムコールの最低限のコストの数百クロックに加えて、 ファイルディスクリプタや引数の値やアドレス空間のチェック、 実装によってはCPUの再スケジュールやその他もろもろが発生するから、 バッファリングされたユーザ空間だけでの場合と比べて何桁かは遅い。 >>235 ブロックして困るようならfgets()なんか使わずに自前のバッファを使うべき。 毎回FILE*のバッファを一杯にしないってのは、一回read()してバッファにデータが 残ってるうちは、満杯にするために再度read()することはないって意味だよ。 複数回read()されると、一度改行を受信してもfgets()から復帰できなくなる。 この場合、条件によってはお互いに半デッドロックって最悪な状態もありうる。 http://mevius.5ch.net/test/read.cgi/tech/1034236536/243
250: 230 [sage] 02/11/01 01:42 >>245 そう？ブロックしても困らない状況は結構あると思うよ。 勉強目的とかでクライアントをお手軽に作る場合や、鯖だとしても、 タイムアウトが必須なほど資源的に程切羽詰まってない場合とか。 でも、alerm()は有効そうだね。 EINTRで再read()する実装あったら嫌だけど(ｗ >>246 究極的には、常にブロックを一切せずに一行読み込むのは不可能。 select()使ったとしても、タイムアウトするまではブロックするわけだし。 ただ、その待ち時間の間に他の事をできるかどうかの違いでしかない。 プログラムの関心がひとつのソケットにしかなく、 タイムアウトも無用であればブロックしようがどうでもいい。 http://mevius.5ch.net/test/read.cgi/tech/1034236536/250
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.033s