http://picavr.uunyan.com/avr_m_logianaPC.html
以前から、ネコロジーＰＣの処理速度が気になって
いるわけですが、これを何とかしようと思って
ＶＢの文字列やメモリ割り当てのことについて
ちょっと調べてみました。
結論：あきまへん。
ＶＢ６の時代には、（開発言語としてはいたって
当たり前ですが）固定長文字列などを使えば事前に
メモリを割り当てしておくことが可能でした。
一方、ＶＢ．ｎｅｔ環境では固定長文字列は廃止
になったとのこと。詳しくはｍｓｄｎご参照。
http://msdn.microsoft.com/ja-jp/library/dd297714.aspx
ＶＢだけでなく、他の．ｎｅｔ環境でも同様みたい。
そりゃ、文字列の長さを考えず、８ビット時代の
ＢＡＳＩＣのように文字列を扱えるようにっていう
のはある意味楽ちんなので、そういう配慮ってこと
なのかも知れないけど、そんなことは余計なおせっかい
で、今回みたいな高々１００ＫＢ程度の文字列を
扱うだけで処理時間をあれこれ考えないといけない
ように縛るなんて、ひどすぎだな。
（ＵＡＲＴから）シーケンシャルに受け取ったデータ
を単に変数に溜め込んで行くだけの処理なんだけど、
これを動的にチマチマと小分けにしたメモリを
（自動的に）確保したり開放したりを繰り返しながら
メモリに溜め込んでいくことになるわけです。
とてもじゃないけどオーバーヘッドが大きすぎる…
現代のＶＢって、数バイト～数十バイト程度のデータ
しか扱っちゃいけないような代物なのーーーー？？？
固定長文字列の様にあらかじめいっぺんにメモリを
押さえて置けば、単にそこに上書きするだけで済むのに、
文字列に数十バイトの文字列を順々に付け足す処理を
行うとなると１回１回文字列を再配置アンドガベージ
コレクションやらなきゃいけなくなっちゃう。
そんなことやってれば、そりゃ遅くなるのは当たり前。
トータルで操作するメモリ量は、回数が増えるごとに
指数関数的に増えていくからねぇ…
そもそもそうならないための固定長文字列とか
ｍａｌｌｏｃとかだったんじゃぁないの？
ＶＢ６からＶＢ．ｎｅｔ環境に換えるときに、
マイクロソフトは
「ＶＢはバージョンダウンします。」
って言っておいてくれなきゃ。こまっちゃうよ。
もしくは代替手段をきちんと作っておいてくれなきゃ。
すこしくらいプログラミングが簡単になったとしても、
固定長文字列が使えないっていうことの欠点に
全然配慮されてない…。
マイクロソフトって、ＰＣの処理速度が無限大に
あるとでも思ってるのかな？わけわからん。
すごいねぇ…マイクロソフト。インテルが誇る
高速ＭＰＵを、２桁処理速度が遅いＰＩＣやＡＶＲ
と比べて格段に劣る処理速度のマシンに大変身
させてしまうとは！
一応、ＶＢ．ｎｅｔのまま固定長を使わず上手い
具合に回避する方法が無いかなぁって思って
いくつかテスト用プログラムを組んで試しては
みました。
だけど、とにかく．ｎｅｔ君は自分の好き勝手に
メモリの割り当て／開放をしたがっているようで、
ダイナミックメモリアロケートさせないような
上手い方法（固定的に確保したところに追記して
行くような方法）がどうしても見つかりませんでした。
…無念。
というわけで冒頭で触れたように、ＶＢ．ｎｅｔ環境
を使う以上、ネコロジーＰＣを今以上に高速化する
ことは無理っぽいことが判ってきました。
たかが１００ＫＢ程度のデータのハンドリングに
困る様な言語仕様とは…とほほ…。
マイクロソフトはＶＢをＰＨＰやｐｅｒｌ、ｒｕｂｙ
と対抗させようとか企んでるのか？無理無理。
そういう無茶なことをするからドンドン使いづらく
なっちゃうんじゃないかな。
金返せー！（無料だけどね）
…困った。他の言語使ってリライトしようかな…
お手軽っていう意味ではＨＳＰあたりか？
ＶＢみたいにビジュアル画面を簡単に編集できて、
言語を覚えるのに苦労しなくて、現代のｗｉｎｄｏｗｓ
でもちゃんと動くような開発言語、なんかないかなぁ…
ＢＡＳＩＣやＣ言語に近いモノがあるといいんだ
けどなぁ。
そういえば、Ｃ言語系（Ｃ＃？）もそんな感じ
なのかなぁ？
…ちょろっと調べてみた感じではやっぱりそうみたい。
Ｃ＃もガベージコレクションを自動的に行う仕様に
なってるって。はぁ。そもそも．ｎｅｔは全滅っぽい。
まぁ、メモリ消費の行儀が悪いプログラムが
プログラム自身やヘタすりゃＯＳ自体を不安定に
していたことも多々あったので、そういうプログラム
の尻拭いを強制的に行うっていう意味ではアレなの
かもしれないけど、でもねぇ…
言語にしてもブラウザにしても、訳わかんない
独自仕様でコテンコテンにして、ドンドン使い
づらい環境を作ってくれるなぁ。某社。
|
おすすめブログ
@goo_blog
