[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 09/07 20:13 / Filesize : 238 KB / Number-of Response : 984
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

シェアウェア作者の愚痴 27



973 名前:仕様書無しさん mailto:sage [2008/03/21(金) 22:26:39 ]
マルチコアを生かしきるほど高速化できるAPIってそうそうあるか?
マルチスレッド化してなくてレスポンスもっさりとか、描画系だけど過剰更新なのを遅延するとかは可能かもしれんが、
大抵のAPIだと基本的に呼んだ時点で処理完了を前提に構成されちゃうからなぁ…。

普通に出来そうな範囲だと

勝手にダブルバッファ化して、ロックしていても再描画することで「固まっている」感覚を軽減する
→描画だけ抜き出すのがメドー。アプリじゃなくてWindows側に干渉する必要がありそう。ってかそれぐらいならレイヤードウィンドウにするだけで済む
描画を自前でキャッシュするなどで制御して過剰描画を抑制して高速化を図る
→描画がネックなら効果的だが、それ以外の効果が薄い。
投げっぱなしAPIを別スレッドに自動分離
→レジストリ書き出し・ファイルIO(CopyFileとかその辺限定)辺りだけで、それがネックの物にしか効果が無いが、それがネックになることはあんまり…
メッセージをコマンド発行系と描画その他システム系で分離してそれぞれ別スレッドに分ける
→API描画系とコマンド発行系で同じスレッド前提だとアウアウ

投げっぱなしAPIは大抵が最初から投げてるからなー…。
APIじゃなく通常のロジック部分こそマルチコア向けに変更すべき箇所だが、これを自動認識するのは骨だ。…上手くいけば効果的だろうが…






[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<238KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef