VBでC/C++に負けないくらいの速いアプリを作ろう

・文字列はStringを使用せずに、Byte配列(Cのchar同等)を使用する。
・文字列や配列や構造体などバイト数が多い変数を関数の引数にする場合、参照渡しをする。
・ネイティブコードコンパイルでコードの実行速度を最適化を選択する。
・最適化の詳細設定をすべてチェックする。
・数値はint(16ビット)ではなくlong(32ビット)を使用する。
・数値型の同じ変数に対しての比較ではIfよりCaseを使う(要するにCaseの数が多い場合)
　(ジャンプテーブルに展開されます)
・画像処理等で1ピクセルずつ扱う場合はPointやPSetを使わず、
　Byte配列で処理しAPIを使用して転送、又はその逆をする。
・クラスのプロパティを何度もアクセスせずにローカル変数に代入してからアクセスする。
・Variant型は使用せずに適切な型を使用する。
・適切な型のクラスを使用し実行前バインディングを使用する。　複数の型のクラスを代入する場合、
　Object型を使うよりインタフェースを使用したほうが良い。(実行前バインディングになる)

これらをすればC/C++等と遜色ない速度で動作します。

その他速度を上げるためのテクニックを書くスレ

Cで作れば済む話じゃん
Cで作れば済む話じゃん

>>2
まあそうだが、書き方が悪いだけなのにVBは遅いというデマを
真に受けている輩が多いので。

>>3
それについては同意

http://pc2.2ch.net/tech/kako/1044/10440/1044028945.htmlの160より


160 名前： デフォルトの名無しさん 投稿日： 03/02/04 23:44

>>142
小さい方から数えて 20000 個の素数をエラトステネスのふるいにより算出する時間をミリ秒で計った。
PentiumIII-800、768 MB、Windows XP Pro SP1、VC++6 Pro SP5、VB6 Pro SP5、Delphi 6 Personal

VC++ （Debug）　　： 10034
VC++ （Release）　：　9724
VB （IDE）　　　　　 ： 49992
VB （P コード）　　 ： 40007
VB （最適化）　　　：　9944
VB （詳細最適化）：　9784
Delphi　　　　　　　 ：　9854

何気に、誤差程度の違いしかなく拮抗している。
漏れは Delphi をよく知らないので改良の余地はあるかも知れぬるぽ。
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1027870433&res=63

1に書いてあるのは殆ど糞。
科学技術計算ならともかくそんな小手先の技法ではわずかしか速くならない。
逆に可読性が下がって生産性も下がる。
書き方が良くないのは1の方だ。
VBは遅くないという部分には同意。
5にあるように普通に書いてれば十分な性能がある。
ランタイムが非常に大きいため（.NETでも同じか）のろい印象を与えるだけだ。

>>1
氏ね

（ ´,_ゝ`） VB厨必死だな

>>3
Srtingを全部Byteだなんて、VBらしくない、悪いコードだよ

（ ´,_ゝ`） VB厨必死だな

Stringで動作が遅くなるなんてライブラリが悪いんじゃねーの
代替クラスつくれよ　

そこまでしてVB使う意味あんの？
VBの利点が全部殺されるだけじゃん……

（ ´,_ゝ`） VB厨必死だな

局所的な高速化を行うのは有効
VCでDLL書くぐらいならVBで高速化したほうがVBらしさを生かせる

VBの高速化なんて簡単。
技術者のスキルアップして無知を改善するだけ。

>>13
マジレス。
VB厨は必死じゃないからVB厨って言われるんですよ。

（ ´,_ゝ`） VB厨必死だな

Cと同じアルゴリズム(ソートかなんかだったと思う)で
数十倍も遅くなったっていうコードを見たら
ループで長めの文字列を関数にByValで渡し、
一文字ずつMid(しかも$なし)で取得していた。

あんたが悪いんでしょって言ったら、逆切れしたので
書き直してやったら、すっかりおとなしくなったよ。

>>12
そこまでって、別にたいしたことじゃないじゃん。
VBでも他の言語と同じようにAPI使うんだし。
所詮パフォーマンスとのトレードオフだよ。

VBが悪いんじゃない
VB厨が悪いんだ

なんてことは20世紀から言われてることでループ内でプロパティにアクセスするようなヤシや
値渡しと参照渡しの違うがわからないようなヤシが消えることはないでしょう
とりあえずDelphiみたいにTipsまとめて普及させりゃ多少はマシになるんじゃないだろうか
コピペはVB厨の最も得意とするところだし

極端な人間がいるな。
別に>>1を絶対守る必要は無いんだよ。
速度が必要な場所だけやる。
他の言語でも当たり前なことがなぜ出来ないんだろうね。

C言語やっている奴がやりそうな勘違い。

C言語では
for(i=0; i<GetCount(); i++) なんてやるよりも
j=GetCount(); for(i=0; i<j; i++) などとやる方がいい。
なぜならループを繰り返すごとにGetCount()が呼ばれるから。

しかし、VBでは始めに一度しか呼ばないので、
For i=0 To GetCount()　というコードは問題ない。

つーか、遅いって言っている奴が馬鹿なんだろ？
比較して言っているやついねーし。
いくら遅いって言っても>>5で証明されてるしな。

>>22
そういう例はVBだけじゃなく、Delphiとかにもある。
しかしＣのやり方を踏襲するのも間違いじゃない。
Ｃ風のやり方をするのを、下位互換性を考慮すると言う。
用はＶＢのやり方が通用しない世界もあるってことを知ってれば
良いということ。
但しＶＢのほうが読みやすいのは間違いない。
ＶＢはＶＢに向いた世界があるんで、無理してＣとかＣ＋＋とじか
ＪａｖａやＣ＃と張り合っても仕方が無いと思うが。

下位互換性＝＝＞下位移植性
に訂正。

>>24
張り合うつもりは無いけどデマは許せないよ。
自分が無知で遅いコード書いてるのに、
言語のせいにしている奴多過ぎ。

（ ´,_ゝ`） VB厨必死だな

一人よっぽどむかついた奴がいるもよう。

>>5
> VC++ （Debug）　　： 10034
> VC++ （Release）　：　9724
> VB （IDE）　　　　　 ： 49992
> VB （P コード）　　 ： 40007
> VB （最適化）　　　：　9944
> VB （詳細最適化）：　9784
> Delphi　　　　　　　 ：　9854
何気にDelphiが一番遅いかったり。まっ誤差程度だけど。

つかVBが遅いのは文字列。
あとは何かというとADOだのDAOだの背負ってるからそういう印象があるんでそ。

>>29
それのソースどこにあるの？

ちゃんとよめ。

終了

Pコードってなぁに？

>>5のように短いソースでなにがわかるのかと。

だれか文字列ソートのサンプルプログラム作ってみてくれ。

sort(a);

（ ´,_ゝ`） VB厨必死だな

>>5
これはエラストテネスとはいわない。素数列挙してるだけ。

こういう話題は８０年代前半の話題。言語がどれだけ低レベルの
機能を持っているかということが重視された頃の時代の話。
今は確実に逆に向かっているのだが。

Delphiの最適化は人力(インラインアセンブラ）で行われるのが普通なので
これは公平な競争とはいえませんね

（ ´,_ゝ`） VB厨必死だな

>>41
おい。(それならC++だってインラインアセンブラで書けばいいじゃん…)

単一関数内での最適化はDelphiは弱いよ。
Delphiはどっちかといえば関数を呼び分けるような場面に強い。

＞40
激同。こんなスレポイ。
| ∧＿∧　|　　 |
|（　´∀｀）つ ミ |
|/ ⊃　 ﾉ　|　　 | 　　◎

VBは遅い。
あきらめろよ。

高速化の話は嫌いじゃないが、いきなり他言語と比べるのはいただけない。
やるならVB同士で、違う記述を比較して、
こういう書き方をすればこれくらい速くなる(あるいは遅くなる)、というのを見るべきじゃないか？

VB的な高速化は>>1で出尽くしてるような……

>>46
別に比較してもいいと思うけど。

納期が目の前に迫ってきたら高速化なんて言ってらんないよ(Ｔ_Ｔ)

>>48
だってVB厨はVBしか使えないだろ(ﾜﾗ
そんな奴らが他言語でかいて比較、なんてやめてくれ。

BasicやDelphiの場合Properyの使い方がカギで、巧く使えばこれほど
簡潔に記述出来る言語は無い。
しかし、これは完全にアセンブラとは逆の方向を行ってて、アサインメント
の際に何が起こるかをトレースすることは関知せず結果のみを重視する立場
を取る。但し速度についてはPropertyを使う場合は結果主義なのだから、
出来るだけ目を瞑らなければならない。
高速化を意識し過ぎるとＶＢの本来の持ち味を殺してしまうことになるな。

かといって大量にまわすループの中でプロパティのキャッシュすらしないのはどうかと思うぞ

（ ´,_ゝ`） VB厨必死だな

>>53
おまえ「必死だな」が言いたかっただけちゃうんかと小一時間(ry

まあ、ちょっとハイソなVBerを目指すスレってことで

（ ´,_ゝ`） VB厨必死だな 必死だな

（ ´,_ゝ`） VB厨必死だな

>>47
そう？
まだあるような気がしないでもない。つか、激しく希望。

（ ´,_ゝ`） VB厨必死だな

（ ´,_ゝ`） VB厨必死だな

おい、誰かVB厨必死だなとか言っている
>>60のような厨を規制しろ！

何かネタを提供したらどこからかえらい人がきてさっと高速化してくれるかも！

Cの三項演算子のようなIIf。
これは関数なのでIIf(A,B,C)のA,B,Cがすべて評価される。
これよりもIfを使ったほうが速い。
If A Then B Else C の場合、評価されるのはAとB、もしくはAとC。

知識が薄くても作れるのがＶＢの売りなんだから
自身を否定するようなことは言わないように

ところでc/c++出来る人むけのVB本ってありますか？
必要になりそうでつ・・・

プログラミング初心者じゃない奴でもこんな事きくのか…

>>5
VB （詳細最適化）：　9784
Delphi　　　　　　　 ：　9854

DelphiはVBより遅いのか。終わったな。

VB厨のやったことなど信用できない。
しらないのにやるなといいたい>>5

比べるならHSPもいれといてくれ

ＣもＶＢもスピードはほとんど変わらない。
スピードは設計とアルゴリズムがすべてです。
しいて言うなら、ＭＭＸの方がよっぽど差がつくよ。

もっと大きいものをつくって比べてほしい。
速度以外の優劣もわかりそう。

>>70
証明してください

VBは遅いって言ってるやつも早いって言ってるやつも机上の空論して楽しい？

DelはVB.NETにも普通に負けてたしな｡

ﾋﾃﾞﾌﾞ

>>5
＞漏れは Delphi をよく知らないので改良の余地はあるかも知れぬるぽ。
VBが負ける可能性あり

くやしかったらやってみろ。>Del厨

ちなみに俺はDelphiなぞ1ﾐﾘもできん

>>43でも書きましたけどさ。

VBつかMSのコンパイラ全般に言えるけど、ひとつの関数内での最適化は
明らかにとは言わないけどかなりBorより上なので、
単純なベンチマークだと.NET含めてDelphiじゃ勝てんよ。
(文字列処理を多く行うとか、相手の苦手なところを突けば別だが)

逆にDelphiに勝たせたければ、__fastcall規約と上手なレジスタ割りつけを活かせるような
複数の関数を何度も呼ぶようなコードで比べればいい。

コンパイラに傾向があるのはどうしようもないっしょ。

（ ´,_ゝ`） Del厨必死だな

ネタ振り。

MID$は新しい文字列を作るので遅いのだろうけど、ならば、
S$のI文字目が"A"かどうかを比較するなら、
INSTR(I, S$, "A")の方が速いのだろうか？？？
(もちろん、INSTRがI以降の文字全てを走査する事を含めた上で)

while(*(s++) != 'A')
関数に飛ばした時点で１０倍遅い

そりゃそうだ

いや、VBスレなんだからBASICの範囲内で…

何でここまでC#の話が出て来てないの？
VB厨必死だなとか言ってるやつが必死なんじゃないの？
高性能なマシーンを使えばいいんじゃないの？

VB以外の話がでる方がおかしいと思うが…

文字が空文字か調べたい場合は、s=""よりもLen(s)の方が速い。
なぜならVBの文字列にはデータ長が埋め込まれているため。

>>5

http://pc2.2ch.net/test/read.cgi/tech/1044116274/
によるとDelphiは100分の1以下の速度になるそうです。

だからDelphiの話も止めてくれ…

>>87
それはアルゴリズムを変化しているからであって、
「Delphiが」ではなく「すべてのものが」速くなるって事。
勘違いせぬように。

>>89
しかしDelphiだけループカウンタをグローバルにしている事に作為的な物を感じる。

>>86
ん？OLEのBSTRは、空のときはNULLでもいいので、
仮に言語が""の代入はNULLをセットしてるとしたら、= ""は単なるポインタ比較で良くて、
Lenの方がSysStringLenの呼びだし分遅くならない？

Caseを使えってあるけど、飛び飛びの値でもそうなの？

>>90
俺もそう思う。
そこだけ改善してもう一度やってほしい。

>>89
しかし、アルゴリズムの改善で100倍も速くなるのなら、そもそもテストの意味がないような・・・

>>89
といいながら、Delphi使いなら、100倍速いコードを素早くかけるという事でもあるわけで、

・・・C屋がいればもっとかんばるのかな？

そもそもはじめに計った奴が
自分の言ってるアルゴリズムを使ってないってのが笑える。

Public Declare Function timeGetTime Lib "winmm.dll" () As Long
Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Sub Main()
　　Const MAX_PRIMES As Long = 20000
　　Dim MaxN As Long
　　Dim Primes(0 To MAX_PRIMES) As Long:Dim ETbl() As Boolean
　　Dim I As Long, J As Long:Dim PrimeCnt As Long:Dim TimeCnt As Long
　　
　　Primes(0) = 2:Sleep 1500:TimeCnt = timeGetTime
　　MaxN = Round(10 * MAX_PRIMES * Log(MAX_PRIMES))
　　ReDim ETbl(0 To MaxN)
　　For I = 2 To Round(Sqr(MaxN))
　　　　For J = 2 To (MaxN \ I)
　　　　　　ETbl(I * J) = True
　　　　Next J
　　Next I
　　For I = 2 To MaxN - 1 Step 1
　　　　If Not ETbl(I) Then
　　　　　　Primes(PrimeCnt) = I
　　　　　　PrimeCnt = PrimeCnt + 1
　　　　　　If PrimeCnt > MAX_PRIMES Then Exit For
　　　　End If
　　Next I
　　
　　TimeCnt = timeGetTime() - TimeCnt
　　MsgBox TimeCnt
End Sub

行数きついので見ずらいの勘弁

VBで書いてみたけど、家のマシンでの結果は9960→1460
でもここでDelに出来てVBに出来ないことが出てきているので、ある意味比較にならん。
今度はCで書いてみるかおもったが眠いので寝る。

（＾＾；）ゝ

自信がある奴、>>1のレスを行単位でバブルソートするコードを
言語ごと書いて、実行速度を調べてくれ。

>>92
ある程度飛び飛びでもなる。
だけどどこかで線引きがあると思う。

>>99
使えない言語に手だしてまた凡ミスするのはやめてくれよ。

強いて言えば、
・不要なDebug.Printを取り除く
・数値型は値渡し強制

どなたか文字列のi番めの文字を調べる>>80>>81以外の(速くなる)方法知りません？

文字列操作にMid$ステートメントを使うと速い

>>103 やりたいことにもよるが、この例ではMid$より10倍ほど速くなる
Option Explicit
Private Declare Function timeGetTime Lib "winmm.dll" () As Long
Sub Main()
Dim i As Long : Dim t As Long : Dim longtext As String
longtext = String(10000000, "A")

t = timeGetTime
For i = 1 To Len(longtext)
If Mid$(longtext, i, 1) = "A" Then
Call dummy
End If
Next i
MsgBox timeGetTime - t

t = timeGetTime
Dim b() As Byte
b = longtext
For i = 0 To UBound(b) Step 2
If b(i) = 65 Then
If b(i + 1) = 0 Then
Call dummy
End If
End If
Next i
MsgBox timeGetTime - t

End Sub
Private Sub dummy()
End Sub

文字列をバイト配列に代入できるのですね…知らなかった。ありがとう

できる奴はなにを使ってもそこそこの結果を出し、出来ない奴は文句だけ垂れる。
おれ？おれはもちろん後者だよ(w

と何気に裏の真理を読み取らせようとする１０７

Object型やVariant型に入っている型を調べるときTypeNameで
型名を調べる人がいるが、TypeOf 〜 Isを使用したほうが速い。
あるインタフェースを継承しているか調べるときにも使えるしね。

http://www.k-514.com/
(σ・∀・)σ　娘です
http://www.k-514.com/img1.html

高速化の一環として、
　Paintイベントを使用するとオブジェクト全体の再描画が必要なので
　サブクラス化してWM_PAINTに反応して必要分だけ再描画する
とかあげてもいいの？

まあそこまでしてVB使うなというのが正解なわけだが。

正直、ＶＢの遅さをＡＰＩ等でカバーする事考え始めたら、ＶＢは卒業した方がよい。

>>105
「For i = 1 To Len(longtext)」
ループ内でlongtextの長さが変更されないのならば、
ループの前でLen(longtext)を変数に代入しておけばよいのでは？

>>113
>>22

ListBox(等)に多量のデータを入れる場合、一度Visible=Falseにしてから入れたほうが速い。

>>112
半分同意だけど、VBはAPIを使うものではないというのは頭が固いよ。

今のプログラミングってのは大部分は楽に作って、
パフォーマンスが必要なとこのみ集中して改良するもんだし。

APIを使えば速いけどVBはAPIを使っちゃダメだから
VBは遅いとかわけのわからないことを言わないように注意。

VBは遅い。

>>116
>VBはAPIを使うものではないというのは頭が固いよ。
誰もそんな事は意っていないようですが。莫迦ですか？

>>118
>>112はもちろん言って無いけど、そう言うやつがちらほらいるんだよ。

誰に向かって物を言ってるのかはっきりしろよ。

>>120
おまえがな。

流れで分かるときはいいだろ

そうでもない

>>102
＞・数値型は値渡し強制

え・・・なんで？
数値はたしかにメモリ消費が少ない場合が多いので値渡しでいいが
強制する必要はないと思いますが。
2つ以上の戻り値を返したいときとか参照渡しにすればグローバル変数を
作らなくてすみますし。

ＶＢって遅いの？コンパイラ言語になったんじゃないの？

>>125
VB5が出たときにみんな期待したんだけど
どの雑誌だかでテストしてガカーリということだった

演算よりリソースのロードとかで
アプリの起動に時間が掛かり過ぎるという話も聞く

>>126
へ〜そうなんだ。
そろそろＶＣの他にもなんか言語覚えようかなあと思ってたけどイマイチなのかなＶＢって。

所詮単純な演算ってたいした量をこなさないことが多い。

オレはネイティブコードコンパイル時に
デバッグ情報の生成→VCデバッグができるようになったことがうれしかった。
だからそこまでするくらいならVB使うなって＞自分

>>127
とてもVCが使える人間とは思えないな。
その口調。

よく、ＶＢには出来ないことがあるのでＶＣを使う
何が出来ないの？

DLLが作れない（ActiveXDLL除く）

>>131
リンカをいじくれば、作れるという罠。

VB.NETならDLLが作れるだろ。

VBとjava、どっちが良いですか

それだったらVB

>>132
その手があったか！
リンカ弄りはヘッダ縮小化で経験済みだったのに気づかなかったよ ありが�d

>>1 には非常に効果のある最も大事なものが欠けている。

それは・・・・・・

結局、VCで出来ることはVBでも出来るってことね！
　わたし、VBしか知らないんです。

>>139
VCの場合、ちまたにあるC/C++の資産をそのまま使える事、
そして何より、そのコードからテクニックやアイデア、思考方法を学べる
事が一番大きい事でしょうね

( ´ー｀)y-~~.｡oO(下手な釣りだな…)

VB.NETの場合、ちまたにあるマネージコードすべての資産をそのまま使えること、
そして何より、そのコードからテクニックやアイデア、思考方法を学べる事がいちばん大きいでしょうね

>>142
買ったコンポーネントにはコードはついていませんでした。
どうやってちまたにあるコードを手にいれるか教えて下さい。

139で〜す。　　
　140,142さん、わかりました。
　　ありがとう・・・・・

VBなんて使うなに一票。

なんでこのスレアンチが逆宣伝しまくってるんだ？
スレ違いだろ。そんなに真実を語られるのが怖いのか？

（ ´,_ゝ`） VB厨必死だな

つーか、>>5でVBは他と同じくらい速いって
証明されているわけで、何を言われても
負け犬の遠ぼえにしか聞こえんわけだが。

>>147
必死で悪いか！
ばーか。

>>148
あふぉですか？
あふぉですね。

ＶＣの知ったかぶり　必死だな。

フォームやコントロールを使うのはＶＢの方が楽とか言うよねん。

>>148
エラトステネスではないけど、コードのパフォーマンステストには
なってるからね。なんかDelphiは(アルゴリズムを)改良したら
もっと速いとか(そりゃ当然でしょ)言ってるけど、同じようにVBも
改良したら(>>96)同じように速くなるし。

C++を使いこなせる者は、VBを馬鹿にしない。

OLEを使うのもＶＢが楽。なのにアーリーバインディングしろ言う1は猫の糞

http://www2.leverage.jp/start/

>>155
おいおい。アーリーバインディングでもOLEはOLEだろ？
なに言ってんだか。

あの程度のコードでネイティブバイナリはいて、差が見えて遅くする方が難しい。

>>154
インディアン研究家である俺の探求心をくすぐったぜ。

いくら言っても証拠がなけりゃ証拠があるものを覆すことはできんて。

>>157
レイトバインディングでもパフォーマンスは十分だし、開発が楽。
必死こいてCOM HRESULTとか調べてるC++開発者哀れだと思ってる。

>>161
別にアーリーでも開発は楽だろ。どちらにしろHRESULTはいらんわけだし。
もしかして参照設定が手間だというのか？
間違った型を入れようとしたらエラーになるし、コード補完も利用できるし。
むしろ逆にアーリーの方が開発が楽だと思うが。

>>160
ループ変数をグローバル変数にし、
エラトステネスのふるいを勘違いしてる奴を信用しろと？
ひとつだけの偏った結果で全てを判断しろと？

限られた予算でシステムを組む、VBになるな。

>>163
じゃあ二つ目の結果を出したら？
結果がなけりゃ所詮口だけだよ。

>>165
わたしが馬鹿でした…

>>166
別に馬鹿とかどうでもいいよ。
結果に基づいた反論が出たほうが面白いんだけどね。
まあそれが出るまでは>>5が有効と。

つーかスレ違い。
各言語パフォーマンス比較のスレでもあったほうがいいんじゃないかな。

参照設定というよりC++みたいに同じオブジェクトを指してるのに違う変数で
表さなきゃいけなくなることが起こるのが嫌＞アーリー

>>168
意味わからん。具体的にアーリーならどうでレイトならどうなるから嫌だと？
あんたが勘違いしているだけじゃないのか？

うちではDelphiで変数をローカルに置いたら約5%(よりやや上)速くなった。
VC++(最適化が可能な上位版)もVBも持って無いので比較はできないが、仮に同じ割合で速くなると仮定して
>>5のDelphiを5%引きすれば、トップになっちゃうよ…

まあ俺も流石にそれは無いだろうと思っているので(Delphiの最適化が賢く無いのは知ってるから)、
多分メモリ配置やキャッシュか何かが影響してるのとは思うが、
それなら尚更、誤差程度の差で騒いでた連中は馬鹿らしいな

実際には、あの短いコードで優劣が出る程の差は、どのコンパイラにも無いと思う。
コンパイラが最適化できるような項目がそんなに無いもん。もっとややこしいコードを使わないと。

もうDelphiの話はいいよ…

>>170
Delphi知らんのだが>>5はローカル変数じゃないのか？

>>169
うーん。なんか俺の食わず嫌いだったかも。まあ趣味グラマなんで勘弁してくれ。

>>169
オブジェクトが複数のインターフェースを持っている時、
いちいち別の型の変数にQueryInterfaceして、Releaseも個別にやらないといけないのが嫌なのでは？

思ったのですがこのスレはVBで組まれたアプリのパフォーマンスを向上させるための技術を話すスレですよね？

いつのまにか馬鹿になってた俺…
>>5が確かな情報でないことがいいたかっただけ。

どうでもいい。
本題に戻りませう。

>>174
VBではRelease相当は自動でやる。QueryInterfaceは他の型の変数への代入。
それはいいとして、レイトバインドじゃインタフェースは呼べない。
レイトバインドで呼べるのはそのクラスのものだけ。
インタフェースを呼ぶときはインタフェース型に代入してからじゃないと呼べない。
そうしないと、同じ名前のメソッドがある別の複数のインタフェースを継承したクラスで
どちらを呼べばいいかわからないでしょ。

VBのANDやORはショートカット演算子ではないので、
(結果が決まった時点で後の評価をおこなわない)
If A And B Thenとするよりも、
If A Then If B Thenとするほうが速いです。

MSがアーリーとレイトの2種類を用意した真意を読み取ろうよ。

>>179
処理部を2度書けってか？

>>181 一度で書けよ。

純粋に、言語の組み込み部だけでコーディングすれば言語間の速度(?)差は殆ど無く
言語毎に用意されたライブラリを使う事で、初めて目に見える差が出てくるモノだと
思ってますた。

Asm、C/C++以外で速度重視のプログラム組んだ事無いのでよくわかんないすが。

>>182
スマンが教えてくれ。どうやって？

>>183
ライブラリも何かしらの言語で書かれているものですけど？

>>185
そりゃそーだ。でもライブラリは言語の持つ思想を重視して作られるから
言語毎に特色ある作りになるでしょ？そこに差が生まれる。

結局コンパイラの性能なんでないの？

市販のライブラリ == 他人のふんどし
自作のライブラリ == 汚れたふんどし

どちらもはきたくない自分はフリチンでなんとかやってます。

（　`Д）　　
/(ﾍ　っ )ﾍ

追記。実生活でもそうです。

オレはブリーフ派

>>184
If A Then
　If B Then
　　処理
　End If
End If
処理は一回じゃんか？

えっ？ 偽が無いって？
処理部を関数にしろ。

えっ？ 関数が二つあるのが嫌だって？
goto使え。
If A Then
　　If B Then
　　　　処理(真)
　　　　GoTo Next1
　　End If
End If
処理(偽)
Next1:

えっ？ Orはどうするかって？
工夫すればできるだろ。
予備知識としてドモルガンの法則でも調べとけ。

忠告しておく、見難くなるので使うのは
パフォーマンスが必要なときだけにしろよ。

>>188
市販のライブラリ == 市販のふんどし
自作のライブラリ == 自作のふんどし
の間違いだろ？

市販のはサイズが微妙に合わないし自作のはたまにハミチンする
上手い例えだな

>>193
いや、間違いではない。

たとえはたとえであって正解はありえないよ。

グンゼなめんな。

＞(結果が決まった時点で後の評価をおこなわない)
は
＞ショートカット演算子ではない
の説明じゃなくて
＞ショートカット演算子
の説明だったのね

検索してみたら意味が逆だったからちょっとハマっちゃったよ

速いとかどうでもいいんだよ。中身だ。中身。

>>192
そんなコードを書くぐらいなら、喜んでパフォーマンスを犠牲にする。

>>192
それ本当に速くなってるの？

>>201
Aが真の場合は変わらず。Aを先にもってくるかBを先にもってくるかの判断は
>>192が統計的手法を駆使して決定している(w

>>202
それ当然の話だし。C言語でもどちらを先に持ってくるか考えるよ。

いや、CPUによっては遅くなってんじゃねーの？って話

>>204
またずいぶんと深いところに･･･

>>200
でもAとBが長ったらしい処理をおこなう関数とかだったら
パフォーマンスを重視するでしょ？
要は書き方で選ぶんじゃなくて場合で選ぶべきだよ。
パフォーマンスとなんとかはトレードオフなんてVBに限らず一般的ことなんだから。

>>204
なんで？ 片方が評価されないことがある分速いでしょ。

mov eax,0 と xor eax,eax
では、後者の方が早い。

でもVBだと、
a = 0 と a = a xor a
なら、前者の方が早い。

>>208
今では　そのアセンブラコードはほぼ同じ負荷だけど、前後のコードで違ってくるよ

VBが作ってくれる機械語をアセンブラにして見てみたいのですが
どうすればいいですか？
全体をアセンブラにされてもたぶんわからないので関数単位で
どの関数はこういうコードになるっていうのを知りたいです

>>210
VB.NETですか？　それならVS上で関数の先頭でブレークポインタしかければ見えるでしょう
VB6だとちょっと厄介です VCは持っていますか？

Declareで文字列やユーザ定義型を使うと文字コード変換や再配置が発生して遅くなるとか
データが破壊されたりゴミが紛れ込んだりするとかは既出？

中途半端にAPI(標準DLL)を使っても結構オーバーヘッドがあったりする。

ソースを拝見させていただいたが、Sleep(1500) とはどういう意味が含まれているのかな？
そもそも 配列で 20000 というのは異常だと考えられる。
Ｃ言語では このような巨大な領域は 先にメモリを確保してからつかうと予測するが これがされていない。
これは、明らかに Ｃの性能を明らかにはっきさせないためであり、また、
ＶＢのＤＬＬのロード時間を確保しているだけの、いわば ＶＢの都合の良いソースである。
というか無駄。

また、テスト環境もいろいろと準備して、１００回以上稼動させ、それに基づき
結果を公表してくれ、メモリや、ＣＰＵがしょぼい環境では どちらが速いか
その点も興味がある。
数値の信頼性がまったくないので、話にならない。

>>213
たぶん　先頭のSleepはそこでタスク切替をさせて　多少なり測定精度をあげたい為でしょ
ただ、実行時間が何秒とかなら、あんまり意味ないのと、1500もは必要ない


配列でローカルに20Kは　5年前なら異常だけど、今はもう普通でしょ。　
あんまり誉められないけどね。

それから、この話題は
Delphi＝ボーランドの【オ　ナ　ニ　ー】では？
http://pc2.2ch.net/test/read.cgi/tech/1044116274/
に移ってるように思うのだが

213の続きだが、

Ｃ使いとして言わせてくれ、
ループ中にある goto文は、continue で代用可能だ。(というか continue だ)
Ｃ言語において gotoは、予測不可能なコードなので、最適化がほとんどかからない。
（計測結果の Debug と Release があまり変わらないのはそのためだ）
なぜ、このようなことをするのか その意図は なんだろうか。
このようなソースを書くＰＧの基本的な能力をうたがわざるをえない。

あと、エラトステネスのふるいだけが、アプリケーションの速度を測るものさしと
勘違いしておられるのでは、ＰＧの世界から足を洗っていただきたい。

ＶＢは あなたにとって良い言語かもしれない。
だがよく考えてくれ、そのＶＢを解析、実行しているものは、なんだろうか。
根本的な知識から勉強し直すことをお勧めする。

Ｄｅｌについては・・・すまん。

>>215
　よーくコードみないといけない
　ここで、continueは使えない
　 gotoを減らす為には、結構複雑な対策が必要になる。

それから、エラトステネスのふるいと書いているが、これはエラトステネスのふるいではない。
エラトステネスのふるいなら、普通に書いても実行時間は1桁以下短くなるだろう。
実際Delphiで書き換えたコードは1/100以下になっている。

こう書き換えればいい
TryPrime:
　　　　for(i = 0; i < PrimeCnt; i++)
　　　　{
　　　　　　if(CurNum % Primes[i] == 0)
　　　　　　{
　　　　　　　　CurNum++;
　　　　　　　　goto TryPrime;
　　　　　　}
　　　　}
　　　　Primes[PrimeCnt] = CurNum++;
//------------------------------
　　　　for(i = 0; i < PrimeCnt; i++)
　　　　{
　　　　　　if(CurNum % Primes[i] == 0)
　　　　　　{
　　　　　　　　CurNum++; //<-- ほんとは CurNum+=2; としたくてしょうがないのだが
　　　　　　　　i = -1;
　　　　　　}
　　　　}
　　　　Primes[PrimeCnt] = CurNum++;

>>216
1/100以下なんてデータはどこにもないけど？

>>218
じゃあ　実行ファイルを作ったからデータを作ってみて
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/file/1050452299_2/TestCon.exe

>>216
失礼、ボーッっとしかソースを眺めていなかった、たしかに continue は使えない。
下の方でも ++ してたのね。

>>217
i=-1; とあるが、無限ループに入ってしまった、
（いや、長かったんで途中で終了させたんだけどね。）
おそらく i=0; だろう。

高速化の手段として、
テーブル作るってのは・・・ながれからいって ルール違反かな？

あと、gotu文についての最適化についてだが、これは私のあやまりだ。
一定の条件のもとでの話だ、今回のような単純なループでは話が違ってくる。
完全に私のミスだ。

最近ミスが多いな、気をつけようｗ

>>220
他言語でも有効な手段を使っても差は縮まらないと思われ。

REM それすらできないのがVB厨だという意見もあるとおもうけど

>>219
作ってみてって、あのさ、データ無いのに100分の1になったとか
言うのやめてよ。そんなんじゃ全然信用できないじゃん。
それとEXE単体でおいてもあやしすぎて実行できません。

>>220
for 文のループで i++ されてるから i=-1; じゃないと正しくないよ。
ただし、ループ変数に代入してしまうと、ループ変数がスタックに割り付けられてしまう可能性が多くなって
逆に遅くなると思うけどね。

>>222
ではソースを
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1050452299&res=2

データ自分で測ってみたらいいと思うけど
自分の環境では、
　>>5　のコードは11203 >>219のコードは103だったよ。

>>221
たしかに根本的な問題ですね。
計算方法は限定されているわけだし、特に、最適化する意味がないかもしれない。
答えをまんま配列に格納したほうが、よっぽどマシな解決方法かもしれない。

>>223
そうなのですか、処理的な流れしか目に付けてなかったもんで、
ついつい さっさとソース化してしまいました。
計算結果の内容は確認しておりませんでした。（マテ


また、タイプミスしてるし・・・
もう、今日は閉店や。

>>225
答えをマンマ配列ってのはルール違反だろうけど　配列を使って求めるのはアリでしょ

それで >>224 より速くなるなら書いてみたら？
>>224も、あと2〜3割は速くなると思うよ。

>>218
1/100ってのはDelオナニースレの奴ね。
>>5の奴の結果が1/100になるっていうわけじゃないよ。
アルゴリズムが違うわけだから。

>>227
でも、結果は同じだよ。

>>224
残念ながらうちの環境では1/100にはならなかった。まあ改善比率はどうでもいいんだが。
>>219コードとそれ同等のVBコードの実行結果。
　　Delphi　14231→273
　　VB　　　14596→432
VBは過去スレに>>219同等のコードがないようなので一番近いコードの>>96を修正した。

ここはVBスレなのでVBスレらしくVBの話。
ETblを>>96のBooleanからByteにしたらうちの環境で100msほど速くなった。
キャッシュの効果だろうか？ Delphiのコード同様、配列をbitで保持したら
どうなるか興味がある。コードが増える分遅くなると思うが。
時間があればやってみるかもしれない。

>>96の改良版
Sub Main()
Const MAX_PRIMES As Long = 20000
Dim MaxN As Long
Dim Primes(0 To MAX_PRIMES) As Long: Dim ETbl() As Byte
Dim I As Long, J As Long: Dim PrimeCnt As Long: Dim TimeCnt As Long

Primes(0) = 2: Sleep 1500: TimeCnt = timeGetTime
MaxN = Round(10 * MAX_PRIMES * Log(MAX_PRIMES))
ReDim ETbl(0 To MaxN)
For I = 2 To Round(Sqr(MaxN))
If Not ETbl(I) Then
For J = 2 To (MaxN \ I)
ETbl(I * J) = True
Next J
End If
Next I
For I = 2 To MaxN - 1 Step 1
If Not ETbl(I) Then
Primes(PrimeCnt) = I
PrimeCnt = PrimeCnt + 1
If PrimeCnt > MAX_PRIMES Then Exit For
End If
Next I

TimeCnt = timeGetTime() - TimeCnt
MsgBox TimeCnt
End Sub

>>229
コードが大きくなっても、キャッシュヒットの効果は絶大だよ。

でも、Delのコードも100倍にならないという事は、
キャッシュが余りない環境なのかもしれないね

試しに MaxN= 224737+512って決め打ちでやってみたらどう？

作業メモリを少しでも小さくするといい。
さらに、２の倍数を最初から取り除くとか

＞試しに MaxN= 224737+512って決め打ちでやってみたらどう？

信じられないかもしれませんが、Delのコードはさらに 1/10になりました。

>>5からの比較だと 1/1000　になっています

まあ、あれだ。　よくいる説教厨のセリフの出番って事だな。

コードのチューニングするよりアルゴリズム練り直せゴラｧ

>>232
VBも同じく1/10になってるよ。

通常の三杯

さてベンチ厨も去ったことだし、
本来の話題に戻りましょう。

VBアプリのボトルネックってどこよ？
　起動時のDLL読込
　実行時のライブラリ内の処理
ネイティブコードコンパイルで解決できないのはこの二つ？

>>237
ボトルネックは、その遅い部分に慣れて遅くて平気な感覚を覚えてしまう所でしょ。

煽りはいらない。

VBだけをやる人の一番の問題は、
文字列を、文字＋列として扱うべきなのに、文字列として扱ってしまう癖が付いちゃう事だろうな。
たとえば、DelフサギコがVBをやってからか　文字列を文字列として扱うようになって
それをDelphiでやってパフォーマンスが出ないと騒いでた。

文字＋列として考えれば、確立されている色んなテクニックが使え、文字列として処理
した場合の10倍100倍ののパフォーマンスが得られる。　

もっとも、短いと判ってる文字列を文字＋列でいちいち処理するのも意味の無い事なんだけど
そこらへんのバランス感覚必要だよね

JavaでいうStringとStringBufferの使い分けみたいなもんだな。

>>239
いや煽りじゃなくて、
速いアプリが作れるかどうかは、数割の差しかでないコンパイラの差じゃなくて、
速いアルゴリズムを実装出来るかの問題でしょ。
ライブラリ部分（OCX含）に引きずられて、速いアルゴリズムが組めないから結果遅くなってしまうのが真実でしょ。

しかしまぁなんと必死なことか

>>243
速いコードを書くにはそれなりに必死に勉強しないとダメだよ。

ただ、方向性を間違えないようにね。

>>242
>>238といっている事がずいぶん違うが。
始めからそう言っておけば煽りだと思われずにすんだのにね。

> ライブラリ部分（OCX含）に引きずられて
ライブラリが遅いとは誰も言って無いんだが。
つーかライブラリはCとかでかかれていると思うよ。

>>245
違うよ。
ライブラリが遅いんじゃなくて、ライブラリやOCXの構成に引きずられてしまうって事を言いたいの。
他の言語に比べてものすごく高機能＝ハイレベルで、しかもそれ単独ではそれなりの性能なんけど、
そのせいで、それをVBコードで繋ぐだけに終始してしまう。

他のツールのように、データ構造を先に作って、アルゴリズムを考えて、そして用意された低機能
なライブラリを組み合わせて構成するという方向に行かない。

VBだってこういう組み方をすれば、まともな速さのアプリが組める筈なのにね。

カールルイスとベンジョンソンが2人3脚するよりジョイナーが一人で走るほうが足が速いようなもの？

ライブラリが高速ならどうして遅いものが出来上がるのだろう

>>246
ライブラリやOCXの構成ってなにを言いたいかわから無いんだが、
OCXやそれと同等のCOMはVB以外にもC++やDelphiでも使え、
実際に多くのところで使われているんだが。

たとえばVBにあるWebBrowserコントロールは
IEコンポーネントブラウザとして、VCではCHtmlView、
BCBではTCppWebBrowserとして同じ物が使われているんだが。

>>248
だから遅いものはできないって結論になるんだけど。
実際に極端に遅いものってないでしょ。

>>247
巧いね。　

>>248-249
ニュアンスが判ってもらえなくて残念だ。俺は教師向きじゃないのだろう。言葉で導く事は出来ない。

>>250
データ数が少し増えれば、極端に遅くなるのがVBのデフォルトのように思われてるぞ

>>251
だから思うのが勘違いなんだって。
プログラムにおいて、論理的に理由を
説明できないことは間違いだよ。

> ニュアンスが判ってもらえなくて残念だ。俺は教師向きじゃないのだろう。言葉で導く事は出来ない。
ただ自分の考えがまとまってなくて、
思い込みだけで発言しているからだろ。

判った判った。　好きにしろよ。

そのWebBrowserコントロールでタブ式の2CHビュアー作ってごらん
確かにテキストをひらって来るのも簡単だし、WebBrowserで表示するのも簡単だし、
それぞれは別に遅くない。

キミらの感覚で作ったビューアが高速になるかどうか見せてくれ

高速なビューアってなにが高速なんだかね。
よくわからないけど、ちまたにあるVB以外で作られている
ビューアと同じ程度の速度にはなるでしょ。
実際は差があるかもしれないけど体感は出来ないよ。
もっとも初心者が作ったらどんな言語でも遅くなるけどね。

>>255
ちまたにあるVB以外と同じスタイルで作れば同じ速度になる。

でも、>>1のようなスタイルが高速化だと思って作ったんじゃ話にならない程もっさりしたものが出来るだろう。

「ライブラリがコンテクストを規定する」ってオブジェクト指向狂詩曲に書いてあったな。
そういうことでしょ？
大掛かりなライブラリは大抵それぞれに最適なデータ構造を取ってるから、
複数繋ごうと思えば妙なオーバーヘッドが出てきて、結局自前でデータ構造を用意した方が速くなったり。

>>240
VB.NET だと Chars で扱えるから多少マシになるかな

でも、やっぱりUnicodeだから　テーブル索引型状態遷移駆動のテクニックが使えないんだよな

http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E7%B4%A2%E5%BC%95%E5%9E%8B%E7%8A%B6%E6%85%8B%E9%81%B7%E7%A7%BB%E9%A7%86%E5%8B%95
0件


UNICODEごときで使えなくなるテクニックって（藁

>>256
不思議だ。速いテクニックと遅いテクニック。
速いテクニックを使っているのに遅くなるとは。
そこんとこ論理的に説明してもらいたい。

>>260
先にアルゴリズムを検討しろって事でしょ。
その前のは、採用可能なアルゴリズムがライブラリによって縛られてしまうからそこが問題だって事でしょ。
それくらいは読み取ってやれよ。

じゃあ別に速いテクニック使うのに何の問題も無いじゃん。
それから他人のふりすんなって。

>>262
　そうじゃない。　>>1のいうテクニックに問題があるんだ。

>>5 を見てごらん、
IDE と VB最適化で 5倍も違うね？　でも５倍の差はデータ数が増えても5倍だ。
しかし、アルゴリズムを修正すれば1000倍になったでしょ？
この差はデータ数が増えれば増えるほど大きくなるのは知ってるね？
　通例では何も考えずにコードを書くと、データ数の２乗で重くなるとか、ヘタなコードだと２のベキ乗で重くなるとのアレね。

5年で10倍の法則は知ってるね？　
5年で10倍になるんだから今遅くても問題ないというのは逆で、
5年でCPU速度と容量の両方が10倍になるんだから、遅いアルゴリズムだと5年先には10倍遅くなるんだ。
逆に>>1のいうようなテクニックは5年先には全く不要だ。

ネイティブコードコンパイルや最適化チェックはそりゃ問題ないよ。
でも、他のテクニックは明らかにコードの可読性を落とす。
コードの可読性が落ちれば修正容易性が失われ、他のアルゴリズムを検討する余地を無くしてしまう。
悪影響しかないんだよ。

>>262
読解力なさすぎ。
なんかずれてるな。

>>263
なにを当たり前の事言ってるの？
それはプログラム全般の話でしょ。
ここはVBのスレだよ。>>1の内容は＋αのことでしょ。

他の言語でも変数はローカルにしろとか多重配列のかっこの順番はとか
キャッシュに入るように工夫するとかあるよね。
それと同じ事だよ。

あと>>105で出てきてるけどStringをByte配列で扱うことで10倍になっている例があるよね。
画像処理も一ピクセルずつ関数で取得するよりかもByte配列に転送した方が大幅に
処理スピードが上がると思うよ。

文盲。

>>265
　ふう。　俺も教師じゃないからここまでが限界か。

Stringについては、確かにVB6までの文字列は 文字+列として扱う方法が無かったから
そういう方法に慣れれるのは大事だし、そういう書き方の方が判り易いからまあいいと思うよ。
ただ、VB.NETにまで持ち込むのはどうかな。

それから、
他の言語で配列の括弧の順番レベルの高速化のテクニックなんて検討もしないよ。
画像処理も、まずはそんな所よりFFTやDDAを検討するでしょう。

> 他の言語で配列の括弧の順番レベルの高速化のテクニックなんて検討もしないよ。
最後にはそこにたどりつくんだけどね。
まだまだだな。

でもまあ、VBで作れるようなショボイゲームでシェア作家になろうって奴には、このスレも十分役立つさ

（＾＾）

>>269
VBでDirectX使えるし、いいゲームを作るための制限にはならないよ。

>>267
VBで速いソフトを作る、最適化するというのがこのスレの趣旨
それ以前の最適化は当然済んでいるのが前提
もちろんそれらの話題は興味を集めるだろうし君がその知識を披露することを
喜ばない者は少ないだろう
可能ならばそれらを使いさらにVBに最適化したコードを示してはくれないだろうか
そうすることはVBコミュニティにとってより建設的だと考える　

C/C++でも、標準のライブラリは(ある程度低機能で高速とは言え)汎用的な作りである為に
速度が求められるコアな部分では標準のライブラリは使用しない。C++では組み込み部さえ
使用しない事もある（極限られた状況下ではあるが）。
なぜならC/C++ではより高速なライブラリを自作する事が出来るからだ。

速度を求めた場合、C/C++で書いている者は他に逃げ道がない。唯一アセンブラが存在するが
世に出ているCコンパイラよりも優秀なコードを書ける、と自信を持って言える者以外は手を
出すべきでは無い。大抵の場合C/C++で書いたコードよりも低速になる。

さて、VBしか扱えない者が、標準で用意されているライブラリの速度に満足出来ない場合
どうすれば良いのか？

そ

VBAの高速化についても語ってほすぃ…

>>274
お決まりだが、処理するときに非表示する。
何の話だったか忘れたけど。

>>274
　出来るだけコードを書かない。

つーか、今更VBで環境依存なテクニックなんか調査してどーすんの？

VBは文字列がある意味ガンで、文字列を使う以上はそれで良しとするしかない。
といっても文字列を使わないようなアプリにVBは最初から不適合。

VB6 なら より世界が狭くなるのを我慢してVB.NETに移行するか、少しガンバッテDelphiやったら？

Delphiなら文字列は配列として扱えるし、他の要素もプリミティブな部分から操作出来る。
VB.NET なら文字列の扱いは改善されてる。

ただし、どっちにしても今迄通りの使い方をしてはダメ 。
構文解析/オートマトン/状態遷移　とかをキーワードに勉強して、文字列のホントの扱い方を勉強しないとね。

> 構文解析/オートマトン/状態遷移　とかをキーワードに勉強して、

低レベルの高速化を議論してるところに、なんでこんなキーワード
がでてくんだよ。

>>278
> 文字列を使わないようなアプリにVBは最初から不適合。
結局自分基準で制限を作って不適合っていっているのと同じじゃん。
文字列として扱うか、文字の列として扱うか。適切なのを選べよ。

（＾＾）

>>280
低レベルでって事は、プリミティブな部分からアルゴリズムを考慮して作る事を言うんだよ
低レベルで高速化って言うならまず、アルゴリズムやれや

>>283
コンピュータ用語の「低レベル」の意味を調べましょう。

いずれにせよ

>272 名前：デフォルトの名無しさん[sage] 投稿日：03/04/17 18:43
> >267
>VBで速いソフトを作る、最適化するというのがこのスレの趣旨
>それ以前の最適化は当然済んでいるのが前提

らしいし。

>>2
で結論が出てるじゃない。 C のような事がしたいなら Cで書くべし。

そろそろ　Cで #define begin { マクロ書くのと同じくらいアホな事やってる事に気付け。

> そろそろ　Cで #define begin { マクロ書くのと同じくらいアホな事やってる事に気付け。
なんでそういう自分基準でわけのわからないこというかなぁ。
はっきり言って全然違う。

じゃ、こういう問題をどう解決する？

問題： 320x240 ピクセルの画像に64x64フィルタ操作を実施せよ


例えば、微分フィルタ＝輪郭抽出フィルタというのは
0 -1　0
-1 4 -1
0 -1　0
　という 3x3フィルタを掛算すればよい

つまらんことやってるな。
こんなことを考えなくてはならんほど遅いコードしかかけんのか？

かけんのさヽ(´ー｀)ノ

そもそも2万個程度の素数を計算させるということがどれだけ比較対象に
ならないかを知らない奴らが痛い。

じゃあ1千万個程度の素数を計算させてみたらどう？

そして比較結果を出してくれ。　

素数を数えて落ち着くんだ…！！

お題：1億以下の素数列挙（1200万個くらい？）

素数 "列挙" アルゴリズムを極めるスレ
http://pc2.2ch.net/test/read.cgi/tech/1018657457/

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

>>291,292,294

おまえらな、マ○コマ○コ連呼してんじゃねーよ

>>297
おまえさ、もう少し大人になろうぜ。

ｽﾏｿ


VBでは実装できないけど他言語では実装できる(高速化用)アルゴリズムってどんなのがある？
実装が難しいとか実装するとかえって遅くなってしまうパターンまで含めて

ポインタ関連で、クラスへの参照で代替できないもの、かな…えーと…
固定サイズのオブジェクトを大量に必要とする時allocatorを自前で用意するとか？

後は、charが無いとか、その辺から探せば幾つか出てくるかも。

charならByteで代用できないかな？

思い出したのはシフト演算が無いんだよね。
あまり使わないけど乗除算の高速化にシフト演算を使おうとして結局*2, /2してしまう罠

リンクリストや木構造は、配列とインデックスで代替するのと、クラスで代替するのとでは
どちらが速いんだろう？

配列の場合 Redim Preserve は結構遅くなる

>>301
文字列がUnicodeだからByteじゃなく16bitが欲しいね

>>299
ポインタが使えないと、ソートさせるのも一苦労

>>305
配列のインデックスを格納する配列を用意するといいよ。

どうも頭が固い奴がいるな。

ポインタ無くてもクイックソートができないだけなんじゃないの？
バブルソートしか使ったこと無いけどさ

>>308
んなわきゃない。クイックソートは、たとえ再帰が出来なくて
ローカル変数すらない言語でも実現できる。
もちろんVBはどちらもできるので普通に実現できる。

VBで作ったソフトをLZHで配布するのに、
COMDLG32.OCXとMSVBVM60.DLLとVB6JP.DLLをLZHに詰め込んで配布したらまずいでしょうか？
ソフトの種類は、ｼｪｱｳｪｱｿﾌﾄです。

>>310
ファイルサイズでかすぎ。糞。

>>308
　違うよ。　バブルソートでも同じだけど、それだと中身＝インスタンスの交換になるでしょ。
　ポインタでソートすれば、ポインタだけのソートだけら　インスタンスサイズ÷ポインタサイズだけ速くなる

答えないで煽る。最低だな。

>>310
標準インストールの場合
C:\Program Files\Microsoft Visual Studioに
REDIST.TXTというファイルがある。
これを見ろ。

ヽ(^^ ) ﾖｼﾖｼ

>>308
よっ！さすがVB厨。

>>312
ポインタテーブルをソートするのも配列のインデックスをソートするのも同じです。
むしろ、ポインタが(32bitCPUでは)32bit強制なのに比べて
配列のインデックスはデータ数にあわせてbit数を減らせるので
ポインタより速くなる可能性もあります。

VB厨じゃないのに煽られた･･･。

>bit数を減らせるのでポインタより速くなる可能性もあります。
遅くなる可能性では？

>>312
よっ！さすがVB厨。

>>317
馬鹿には変わりない。

>>318
キャッシュに入る確率が上がるので
速くなるでしょう。

ありがとうございます。
問題ないことが分かりました。

32BitCPUでは32Bit型同士の演算が一番速いとだけ言っておく。

少なくとも同じアルゴリズムだったらVBよりもC++（C)の方が圧倒的に速いよ。
だからといってVBが糞とは全く思わないけども。

少なくとも同じアルゴリズムだったらVBよりもDelphiの方が圧倒的に速いよ。
だからVBは糞だと思う。

http://homepage.mac.com/hitomi18/

ヾ(゜▽、゜)ノ パトリシア……

この板の釣厨たちを見ていると
「デジドカ」の意味がよくわかる。

VBって、例えば符号無しの型が用意されてない部分だけ見ても、かなり出来る事が限られるね。
変換すりゃいいって言われるかもしれんが、それじゃ結局遠回りだし、やっぱり
元から簡単な処理する為に作られたもんだと思うよ。

VBでC/C++に負けない速度の物を、とか考えるのはVBしか使えないヤツでしょ。
>>1に書かれている事を実践するより、アルゴリズム見直した方がよっぽどマシだと思われ。

>>329
　その助言は何10回となされたのだが、受け入れられないのだ。

>>316
　もしかして　構造体配列を作って、その配列index配列を作ってソートしますか？
　となると、構造体毎にソートアルゴリズムを書かなければならなくなりますね。
　そういやコールバック無かったか

>>329
結局VC/Delphiには勝てないとわかった上で
どこまで高速化できるかを楽しむためのスレにしようと言う話が少し前にでていたような気がする。

あとはVB厨がはまりやすいボトルネックを見付けるのにも有効かと。

>>332
プログラミングで高速化というのは、あくまでもアルゴリズム改善の事であると判った上で
の話なんだね？　
　そういう事なら、課題を考えて、それをどうするかという方向の方がいいんじゃないの？

一般的な話として>>1のようなのが出ると、勘違い厨量産の方向になって全く良くない。

VBが遅いのはプログラマの技量が低いのが最大の要因、と何度もガイシュツだが、
何かと話題をVB　vs　Del(C++)にすり替えたいらしいアフォが多いのでな。

>>331
なんで構造体ごとに配列index配列のソートを作らなきゃならんのよ？
中身のソートとポインタ(配列index配列)のソートの区別ついてないだろ。

>そういやコールバック無かったか
イベントでも、Strategyでも好きなものを使えばよい。

>>333
もちろん。そのためのﾈﾀﾌﾘを何度かしている。
下手に課題からベンチマークで速度を測ろうとするとVC厨・Del厨が暴れそうなのもいやなんだよね。

所詮ｶｰﾄはF1より遅い。
けどｶｰﾄの最速を求めるのは悪くないよね。

あとVBじゃマルチスレッドを(まともには)使えないと言うのもユーザの体感速度には影響するかな？

じゃあ　x,y,z 座標を持つ構造体配列を作って　z 順に描画させるという課題でどう？

>>335
　比較関数をどうやって渡すんだ？

クラスで渡せってのは、このスレではダメなのか？

アルゴリズムで高速化うんぬんならわざわざVBに話を限定することは
ないだろよ。

>>340
それは違うな。
ＣやPascalスタイルで開発されてきた普通のアルゴリズムを利用出来ないからこそＶＢは遅いんだ。
だから、VBで高速化したいなら、普通じゃないアルゴリズムを開発する必要があるって事だ。

>>337
ソートより描画がボトルネックになりそうな予感

>>341
97%程同意

>>338
ちっとはオブジェクト指向プログラミングを勉強しろ。

>>341
> ＣやPascalスタイルで開発されてきた普通のアルゴリズムを利用出来ないからこそ
利用できないアルゴリズムってなんだ？
ソースが利用できないってなら分かるが。

>>337　の課題の更新

　ボールが沢山箱の中に入っている。　重力は下に働き、
　ボールの描画は単なる塗り潰し円として、その半径を、
　箱の外からの視点からの距離に逆比例するとして描け。

　半径r0、視点位置(x0,y0,z0)は初期設定、
　ボールの個数Nは10個より開始し５秒毎に1個増やすものとする。

　初速、初期位置はランダムに設定せよ。

反射について、
１、ボールの入る箱を大きな球として
２、正方形として
　好きな方で反射するものとしてよい。

　ボール同士の反射は行わせてもよいし、無視してもよい。

宿題は自分でしろ。

この課題は
単純に、構造体配列に取る方法では、最大ボール数が決まってしまう。
　配列構造だと動的にボールの追加削除は難しいし、遅くなる。
だからヒープに作成して、Zオーダでポインタをソート。
　ソートは最初の1回目はクイックソート　
　ループ中は、座標更新後にバブルソート
描画はソートされたZオーダ順にメモリビットマップに塗り潰し円を描けば良い。

>>347
実際に実装しなくていいんだよ。　VBならこういう実装するという議論が出来ればそれで

つまり勘違いしたやつがスレ立てて、勘違いした奴らがあつまって、
煽りに対して、いいわけしてる内にわけのわからんことになってると。

スレ主は自分の言いたいこと分かってるし、
レスしてる人間も分かってる。

ただ、わかってない人間もいる。
それだけ。

ここまで議論の流れ

VBでもC/C++に負けないくらいの実行速度を出す方法はある。
VBのコードを実行速度で最適化しよう。
↓
C/C++で書けば？
↓
VBでも書き方でいくらも早くなると言うことを示したい。
↓
プログラムを早くすると言うのはアルゴリズムを練る事だ。
小細工をして保守性／可読性を下げるのはよくない。
そうまでしてVB使いたくない。
↓
別にコーディング技法で実行速度を最適化するのは悪いことじゃない。
全部のコードを実行速度で最適化する気になる必要は無い。
状況によって必要な個所を速度で最適化すればいい。
パフォーマンスと可読性／保守性のトレードオフ。
↓
＊以下議論ループにつき割愛。

問題提起からの分流
・空文字列チェックはs=""よりLen(s)=0が早い(>>86)
→そうか？(>>91)
・VBはOLEを使うのが楽なのにアーリーバインディングしろ、はおかしい。(>>155)
→はあ？(>>157)→(>>161)→(>>162)→(>>168)→(>>169)→(>>173)
→（分岐）→(>>169)→(>>174)→(>>178)

その他ご意見：
文字列を値渡しするな。
Midとかは$つけろ。
ループの中でプロパティさわりにいくな。
For i=0 To GetCount()というコードは問題ない。（>>22）
IIfはIfより遅い。(>>63)
不要なDebug.Printを取り除く
数値型は値渡し強制(>>102)→なんで？(>>124)
Object型やVariant型に入っている型を調べるときTypeNameで型名を調べるより、TypeOf 〜 Isを使用したほうが速い。
Paintイベントを使用するとオブジェクト全体の再描画が必要なのでサブクラス化してWM_PAINTに反応して必要分だけ再描画する
表示中のコントロールの変更の時は、再描画を停止する／非表示にする。(>>115)
If A And B Thenとするよりも、If A Then If B Thenとするほうが速い。(>>179)
Declareで文字列やユーザ定義型を使うと文字コード変換や再配置が発生して遅くなる。(>>212)
ReDim Preserveは遅くなる

サンプルコード：
・>>96-97→>>229-230→>>231-232
・>>105（>>103に対して）

初心の頃に　VB 最適化　とか　VB 高速化　でぐぐったものだ

age

＞表示中のコントロールの変更の時は、再描画を停止する／非表示にする。(>>115)

これはVB以外の言語でも使えそうな気がする。
こんど試してみよう。

>>356 他の言語も使えるのに、やってなかったのか？

でも処理の都合でリストビューのオブジェクトが急に消えたらユーザーがビックリするのでは？

停止するだけで十分

>>358
画面更新してなきゃ表示されたまま。

DGCAの描画が遅いのはそれが原因か>>115

DelphiならTListView.BeginUpdate、EndUpdateでお仕舞いなんだよな。

VB.NETもBeginUpdateでいいね。

C++BuilderもBeginUpdate

VB.NETを使えばC/C++に負けないよ。

>>365
なんで.NETアプリはあんなに起動が遅くメモリを大量に消費するのですか？

仕様です

>>367
嫌な仕様ですね。致命的です。

ってか嘘だし。

ということにしたいのですね。

>>368
そこらのプログラマが書いたコードが
５年先にまともなプログラマが今書いたのと同じ程度のパフォーマンスが出るように設計されてるからです。
ただし、5年後にそのコードが動くパソコンを探すのに苦労するでしょうが

>>371
何を言いたいのかサッパーわからん。

翻訳開始：

重いったって5年先にゃマトモに動くさ。
今重いから、ｵﾏｴﾗみたいなバカが書いて重くても言い訳できるだろ？
そしてｵﾏｴﾗが書いたクソ重いコードも5年先にはマトモに動くさ。

ただし、5年先に動く環境作るのは大変だろうがな。

翻訳終了

#しかし、アルゴリズムの選択ミスなら、5年先には3倍重くなってるだろう

なんで、そこまでしてVB使いたいのかと。

そういう傾向があるんだよ。
basicだと簡単な事が簡単に出来る。
で、入門書も、キーボード操作から教えてくれてて、
なんか作れた気分になる。
だから、もっと大事な筈の基礎をはしょってしまってる。

そんなわけで実際に遅いとなると、アルゴリズムの改善じゃなく、小手先のテクニックを探そうとする。
あるいは、遅ければ速いパソコンを買えという。
＃工賃の方がパソコン買い換えるより高いからとね。

で、それは多少効果があるように思えるだろう。
しかし、アルゴリズムが改善されてない限り、データ量が少し増えただけで無意味になる。

ほんとに速いアプリが書きたいなら

１、きとんと構造化する事
　　　gotoを使わないのが構造化じゃないよ　数学的帰納法と、抽象化が一番大事な点
　　　この２つはちゃんと勉強して自分から訓練しないと身につかないから注意ね。
　　　高速化したいなら、目先の高速化の為にサブシステムに分解するのを止めたりと愚なことはやめて
　　　きちんとサブシステムに分解して、高速化するべき個所の分析、変更を容易にする事が大事

２、代表的なデータ構造とアルゴリズムの内実に触れる事
　　　これらは体系化され、誰でも簡単に勉強出来るようになっている。
　　　それなのに逆に学ぼうとする人が減ってる現実がある。
　　　これらそのものがライブラリに組み込まれて、それを使うだけになってしまってるからだ。

　　　しかし、高速化したいなら、どのアルゴリズム・データ構造を取るべきかというのが一番肝要

構造化する時に一番大事な事は　命名する事

命名する事は概念を作る事でもあって、　とても重要だね。

>>375
別に VB に限ったことじゃないじゃん。

>>378
　他の言語は、いきなり型とか何とかで適性ないと躓くからなあ

>>379
でも...
>適性ないと
と言うことであれば、早めに躓いた方が本人のためだよね。

定期あげ

構造化が高速化につながると信じられているみたいだが、余り関係ありません。
構造化はプログラムの記述を簡潔にし同時に変化に対して柔軟にするだけです。
保守性が高まるというわけです。
本質的な意味での高速化はデータベース化とそれと連動したアルゴリズムの改善
でしか為しえません。用途に応じてハードウェアにデータベースを組み込んだり
します。

>>382
そのデータベース化って
普通に言うDBを使うとかじゃなくって
処理に時間のかかる関数の結果をあらかじめ用意してしまうという方のでしか？

>>383
概ねその通りですね。

ハードウェアにデータベースを組み込む？
>>383 は読んだがそれでも変な感じがする。

ＤＢというと頻繁に更新されるものという固定観念があるけど、
めったに更新されないものだったらハードに組み込んだほうが
効率的ってことでしょ。

>>384
ハードに組み込むってのは　即値として入れるって意味かい？
ハードウエアって意味じゃないよね？

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

プログラミング初心者じゃない奴でもこんな事きくのか…

ハードコーディング?

あらかじめテーブルにdegreeごとに128倍したsin/cos値を格納して高速化とかやったっけ・・・

FFTするのにかい？　それは当たり前の手法で、テスト以外でそれをしないと普通笑われる。
だいたい、その種のテクニックをハードに組み込むって言い方はしないよ。

ROMに書き込むようなソフトやLIBでしか提供されない種類のソフトの事をミドルウエアとか言う場合はあるけどね。

ちなみに、ゲームとかで使うなら 度単位じゃなく、 256*x/2π にするけどな

VB.NETもBeginUpdateでいいね。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

>>374
会社が使えというからさ

（＾＾）

試みは面白い。あげ。

VB使ってる時点で負けているのでsage

言語は手段にしか過ぎないと思うが、VBを使って負けという意味がわからん。
そういうやつがどんなアプリ作っているか知りたい。

>>401
相手にするなよ。VBすら使いこなせないヤツを。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

その手段がVBしか無い=負け
使い分けてるヤツは別だけどな

ヽ(^^ ) ヨシヨシ

VBしか使えないやつに限って使い分けろとか言うワナ。

>>1
そこまで無理してVB使わなきゃいけないなら素直に
他の言語使った方がええんとちゃう？

>・Variant型は使用せずに適切な型を使用する。
コンテナ使う以外にヴァリアントなんてつかうのか？

>>408
データベースでは各データ型にNULLを代入することが出来る。

VB糞すぎ

アンチ 馬鹿だね

バリアントはどうしても必要な場合（強要される場合）にのみ使ったほうがいい。
メモリコストも実行時コストも高いしさ。
もっとも自己再定義できるプリミティブなデータ型ってのはいいけどね。

ついでに言うと、バリアントはタイプセーフじゃないからコンパイラでエラーがでずにラインタイムエラーが発生するリスクが増える

>>1
>> ・数値はint(16ビット)ではなくlong(32ビット)を使用する。

これって何か意味あるんですか？
データ転送料2倍で、遅くなるだけ何じゃ。。。。

少なくとも、C、Java　で実験すると1,2,4,8 Byte 単位で処理をするとちゃんと順番に遅くなるのですが？

コンポーネントをVCで書いてVBで呼び出す

これをすればC/C++等と遜色ない速度で動作します。

>>415
しません

---終了---

コンポーネントをVCで書いてVBで呼び出す

これをすればC/C++等と遜色ない速度で動作します。

すくなくとも>>1の小細工はしなくていい罠
コードは１行だしな

>>414
それは実験のやり方がわるい

出来の悪いコンパイラだと、WORD でも DWORD で計算する為にゼロ拡張したりゼロ詰めしたりするんだよな。
だからベンチマークが遅くなるわけ。

ただ、>>414 の言う通り、実メモリとの転送幅はそれだけ小さくなるし、実メモリはキャッシュに比べて極端に
遅いから、一般アプリだと小さい幅にした方が実速度は速くなるんだよね。

VBとVCの一番の差は、何て言うんだっけ？　ウインドウのサイズを変えると配置されてるアイコンの位置が
それに合わせて変化するやつ。

VBとVCの一番の差というより、いわゆるVisualプログラミング系言語とVCの差というべきもの。

Visualプログラミング系言語＝フォームにペタペタ部品貼付で画面作れるやつね。
これはイメージをそのまま保存するからダメなんだと聞いたことがある。
VBに限らずDelphiでも、C++Builderでも同じこと。

今でもそうなのか？

>>420
http://www.microsoft.com/japan/msdn/vsisv/boc/vsresizer.asp
VS-Resizer　の事を言ってるの？
Delphiにも似たようなコンポーネントは売ってたよね。

VC++のダイアログではそれが出来ないと？

>>421
よくまあそんなデタラメを(ry

>イメージをそのまま保存
意味がわからん
ビットマップにでも保存されてると思ってるのか？

ああ、VCL用のリサイズコンポーネント（フォームに貼り付けるだけで再配置してくれるやつ）もあったね。
でも、
VCLの場合は フォームにパネルを配置しておいて、Alignプロパティで動き方を決めておいてから
アイコン類を配置して、アイコンはAnchorsプロパティでパネルサイズが変化した時の動き方を決めればいいし
その方がユーザも使いやすいからなあ。

もし、リサイズさせたいなら、起動時に位置を全部記録しておいて
リサイズイベントで処理すればいいから、そんなに手間じゃないし。

>>422
いやいやVC++なら出来るということ。

>>423
デタラメなのか？（ｗ

>>424
実際にはビットマップとまでは言わないよ（ｗ
分かりやすく例えればの話。
ペイントのファイルと、ＣＡＤのファイルの違いに例えて説明を聞いたことがあるんだが？

>>427
ぜんぜん判ってないみたいだよ。その人。

VB なら .frm Delphiなら .DFM にフォームの位置情報が入っている。
そして、実行中に、位置情報を統一して処理するのは　初歩的な処理の一つだ。

>>428
そうなの？
VC++との比較の中で出てきた話なんだけど。

つまりVC++の優位性って一体なんなの？
プログラミングスタイルのレベルの話じゃなく、できあがったアプリに出てくる差とは？

MFCも似たようなもんだろ

>>429
　結局使う人の差だよ。 VC++ならあんまり酷いレベルだとそもそも動くように作れないってだけの話さ。

VC++の優位性は唯一 M$のサンプルコード(SDK)がそのまま動くという事のみ。
まあ、MFCxx.DLLがOS標準で存在するのがメリットと言えるならメリットくらいかな。
他のツールに比べて開発時間もかかるし、要求される作業員のレベルも高くなる。
　しかし、だからこそVC++でわざわざ作ればそれなりの性能になる。　そりゃ時間も金もかけてるのだから当然だ。

ただし求めるものが性能なら、VBは無理としてもDelphiでもBCBでも同じ程度の性能は
もっとコストをかけずに実現出来る。

>>432
ただし、ハイアリング・教育・メンテナンスコストは増大するがな。

>>419 さんわかってますね！
414 書いた者です。

>>418 は実務アプリを組んだこと人ね！

わかっている人もいて安心！
２次キャッシュに入るかはいらないかは大きいですよね！
まぁVBだとあんまり恩恵ないのかな、それぐらい遅い。

VBは、Java よりもはるかに遅いです。ドロー系、CAD系　実務アプリでチェックしています。
&100Mぐらいのデータをメモリー内での処理なんてのもやってみました（実務用にね：ベンチマーク専用ソフトじゃなく）

VBが早いってのはそう思うぐらいCPUが早いのとあんまり処理をしていないソフトだからです！
まぁその程度のマン・マシンだけのアプリなら、VBでも十分と言えます！（あるいみJavaより使いやすいマンマシンですからね：人間の操作する時間はCPUに比べて極端に遅いからね！）
でも、処理を考えるとVBよりJavaの方が早いです。もちろん C の方が早い！
But へたくそな mfc プログラム（素人作成の）は、Javaより遅いことも多い

どうでもいいけど、日本語勉強しようね。

VB用のSTLを作るとか。

VB用のインラインアセンブラを作るとか(昔のように文字列に埋め込んでCALL)

VMにもよるのですが、Javaはそんなに速くありません。
あの手のバイトコード変換型のシステムはJITTERのファーストロード時のオーバーヘッドが大きいので、
少なくても同一コードが２回以上実行されないと、コストの回収ができず、
ネイティブコードをダイレクトに実行するプログラムよりはるかに遅くなります。
これは、.NETのランタイムシステムも同様です。CLRのローダもバイトコードのコンパイルを行い、キャッシュをして実行時のコストを回収してます。

ちなみにVBが遅いというもの事実です。ただし、VBの遅さはVBのコンパイラが生成するコードの品質が悪いのではなく、
VBのランタイムライブラリの組み込み関数がとても遅いため全体的な処理速度が劣化します。
シンボル情報をつけてコンパイルして、生成コードをVCのデバッガで確認するかSoftIceを使えばわかりますが、
実際、浮動小数点などの演算を行う部分の生成コードの最適化の質は、VCのコンパイラのC2フェーズの最適化と同じことが行われます。
かなり高度な最適化が行われてることがわかります。

> VBのランタイムライブラリの組み込み関数がとても遅いため
実際に確かめた結果？ その根拠は？

>>437
現在は、OSが実行コード部分を改変できないように、プロテクトをかけていますので簡単ではありません。
コードの書き換えを行うとすると例外が発生してOSによってスレッドが例外ハンドラにつかまり、プロセスごとシャットダウンされます。
ただし、この手の自己改変可能なコードはメモリのプロテクトを外せば変更できますし、それを元に戻せば、実際に実行できます。
以前、UDT（ユーザー定義型）=構造体に、Intelのマシンコードを入れて実行させたことがあります。
ただし、Alpha版（今はなきDECの石）のVBにポーティングするようなケースでは止めたほうがいいです。

だからさ、ゲームでも作らない限り、プログラムが速い遅いに
コンパイラの品質なんて関係ないのよ。

大事なのは、アルゴリズム。　

その処理にもっとも効率の良いアルゴリズムを適切に採用出来るかどうかが重要。

>>440
文字列のある領域は実行コード部じゃないから　CALL さえすれば実行出来るだろう

>>439
プロファイラを使って動的解析と静的解析をして評価しました。
もっともこんなことをしなくても、デバッガを使えば生成されたコードをみれば、
どのくらいランタイム関数を呼び出してているのか、そのオーバーヘッドがいかに大きいかすぐにわかります。

>>437
アドレス忘れたけど、既に商用である。

>>441
禿げ同。だからVBが遅いって行っている奴。
あれは自分のアルゴリズムが悪いだけ。技術力不足なのさ。

>>443
具体的にどの関数？

>>442
データ部分は、リード可能、実行不可で、マークされてます。
デバッガ上でEIPレジスタのアドレスをそのデータへ変えて１インストラクションでも実行させれば、例外が発生します。

>>446
文字列操作系の関数は特に時間を消費します。MidでもLeftでもいいのですが１行だけ呼び出すコードをSub Mainに書き入れて、
シンボル情報を生成して、デバッガで確認すればわかるかと思います。

>>445
アルゴリズムの改善は劇的な処理速度向上が見込まれることがありますが、これは処理系に依存したことではありません。

さらに言うと、VBはOn errorを使うと遅くなります。
通常、スレッドに対してエクセプションハンドラを関数の呼び出しを設定すると、
例外発生時にリワインダーをかけて例外を処理できるハンドラを探すのですが、
VBの場合、呼び出し元の関数でOn Errorで例外ハンドラを設定すると、それ以降、ネストして呼び出す関数すと、
必ずスタックフレームに例外ハンドラを設定されますし、
例外が発生するとリワインドされて処理できる関数へ戻るオーバーヘッドがかなり大きいです。

VBでアセンブラを実行するサンプル
http://members.tripod.com/~masapico/doc_FuncPtr.html(死んでる？ ↓googleキャッシュ)
http://www.google.co.jp/search?q=cache:P38QdU0CPmUJ:members.tripod.com/~masapico/doc_FuncPtr.html

>>450
try-catchもそうだろ。

>>448
> 文字列操作系の関数は特に時間を消費します。
なんに比べて？ まさか文字列が存在しない言語と比べてるとか？

>>447
いえ、残念ながらWindowsはフラットメモリモデルを採用しているので
リード可能で実行不可という状態は作れないと思いますよ。

>>449
いえ、VBだと自由にアルゴリズムを選択できないから遅かったのでしょう。

>>452
VCのC++などのｔry catchも実質的に例外ハンドラの設定を行うという点では同じなのですが
C++の場合は、関数単位できちんとスタックフレームの形成をコントロールできます。
また例外を処理できるハンドラを探すリワインダは、実際の例外コードのみを渡して処理できますが、
VBの場合、常に単一のハードウェア例外を能動的に発生させて、
例外の情報の詳細はVBのランタイム関数の内部で解析するようにできています。
（VBのランタイムエラーをErrorステートメントで起こしてデバッガを見てる、常に単一のハードウェア例外しか発生しません）

> いえ、VBだと自由にアルゴリズムを選択できないから遅かったのでしょう。
そういや、VBにはポインタがないからリストを作れないとほざいていた奴がいたな。
参照はあるから同じようにリストは作れるし、
たとえ参照が無くても配列とインデックスでリストは作れるのに。
そんなやつが遅いと言っているんだろうね。

>>455
ということは別にVBだからって遅いわけじゃないね。

> さらに言うと、VBはOn errorを使うと遅くなります。
さらに言うと、C++はtry-catchを使うと遅くなります。
と言っているようなもん。
何かやったら遅くなるのは当然の話。

>>454
では、ユーザモードのプロセスから、カーネルモードのコードを読めてしかも実行できると？

454からどうして458のような質問が出るのか。

>>456
たとえば文字列の扱いは？　
>>1 のように配列にして配列アクセスしても遅いのはどうでしょう？
Delphiの文字列のように配列がポインタアクセス並とはいわないけど
検索はInstr強制みたいなのは　アルゴリズムが制限されてるとは言わないの？

>>457
いいえ、違います。VBのランタイムエラーの処理の方法が、設定されたVBのランタイムライブラリでしか解析できないようになってるため、
つまり通常のエクセプション構造体に情報を入れずに、VBにしかわかないような方法を取ってるため遅くなります。
デバッガでスタックフレームの冒頭で設定される例外ハンドラの先のアドレスを確認してみてください。

>>457
やめとけ。議論になってないぞ ﾌﾟ

>>459
そうですね、言いたかったことが少しおかしいです。
アドレッシングとメモリアクセス制御の関連を、リングの特権の問題にすりかえてしまいました。
では改めていうと、同一プロセス内のメモリであれば、どのアドレスでもリード可能、実行可能だと？

ではこの辺でいつもの一言を。

>>457
VB厨必死だな(w

>> 462
そうでもないです。私も最初は462と同じように考えましたし、そう思って調べた経緯があります。
そもそも例外ハンドラとは処理系依存ですし、正確に言うとVCの場合、tryとかcatchは関数の実体があるわけではないですし、
さらに複雑にしてるのは、例外ハンドラやエクセプション構造体の情報がSDKやDDKにほとんど記されてないのが問題です。
これはM$の怠慢です。

まちがえました。。。。
>>462
そうでもないです。私も最初は457と同じように考えてました。

色々と書いたのですが、やっぱVBはM$にランタイムのコードを開示してもらえないと厳しいです。
その都度、デバッガで追いかけてマシンコードを解析しながら調整するのは辛いですし。
そいうゆう意味ではMFCもATLも他の処理系の多くもソースコードがついてますので、安心です。
VBでも速いコードは確かに書けるのですが、内部解析をしまくる必要があるのは他の処理系よりも大変ですし、VBのメリットを失ってしまいます。

>>463
それもおかしなスリ換えだね。

OSの仮想記憶機構によって　ページ単位にRead可能 Write可能がそれぞれ設定出来る。
しかし、実行可能かどうかについてWindowsでは設定出来ない。

ただし、Read可能でなければ実行も可能ではない。

IA64は 実行可能かどうか独立に設定出来るんだろうな？

それが無いとそろそろ厳しい。

>>468
それは正しいです。ただ、話をしてる内容はカーネルモードの仮想メモリマネージャのページング機構の話ではありません。
ユーザーモードプロセス空間のメモリの保護と実行権の話です。

>>470
ユーザモードで実行権を独立にコントロール出来るアイデアをもってるなら
さっそくマイクロソフトに売り込め！　高く売れるぞ。

>>469
ただRead可能であれば、実行できてしまうということは、
データが格納されているアドレスに誤ってEIPが設定さｒた場合、コードの実行ができてしまうことを意味します。
それはないとはずですが、とはいえ、私も少々気になるところがあるので調べてみます。

>>472
もし、スタックに実行権を禁止出来るなら
もし、データ領域に実行権を禁止出来るなら、
バッファオーバランはセキュリティ問題と無縁だったろうね。

ビクッ. ∧ ∧ ∧ ∧　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 Σ(゜Д゜；≡；゜д゜) ＜　うお！なんかすごいところに迷い込んじまったぞゴルァ！
　　 　 ./ つ　つ　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　〜（＿⌒ヽ　ドキドキ
　　　　 )ノ ｀Jззз

>>473
確かに！でもデバッガはInt3を埋め込んでもいないのに、確かに停止し、実行権があるかどうかをチェックしてます。
もちろん、CPUのステップ実行ではありません。
シンボル情報だけではできないので、デバッグを行うCPUのコードを使ってると思うのですが、それにしても解せません。

>>473,468
観測的な情報なのであまりエンジニアらしい論拠とはいえないので申し訳ないのですが、
VirtualAllocやVirtualProtectExでは実行権の制御の設定はできます。
これを実現するには、普通に考えてOSというよりCPUの機能支援がなければ無理です。
とはいえ、まだ調べきってないので、間違ってるかもしれません。もう少し時間が必要です。

間違えました。
４５７ではなく４７５です。

良スレあげ。VB使いの技術力の高さが良く分かる。

だから>>451でVBから
アセンブラを呼び出しているだろ。
メモリを確保してMoveMemoryで命令を転送して実行。
これは可能。

>>473,468,479
VirtualProtectExの動作チェックをしました。結論から言うと468の言ってることは正しい。
つまり447で言ってるデータエリアへEIPをセットして実行しても「例外は発生しない」ことが正しい。
メモリ保護属性をチェックしたがデータエリアにEIPをジャンプさせて例外が発生するのは、PAGE_GUARDだけ。
言い換えるとPAGE_EXECUTE_READもPAGE_READONLYもコードの実行ができる。
つまりデバッガはメモリアクセスやコード実行の異常をPAGE_GUARDの例外に引っ掛けてチェックしてる。

このスレ、やけに気合の入ってんな。マジレスの応酬じゃねーか。

>>481
しかしﾌﾞﾋﾞ厨にはその議論の全てが理解できない罠。

どうしてVB厨はあれだけDelスレ荒らしまくりなのにCBuilderスレは荒らさないのだろうか？

ＶＢ厨が被害妄想の塊でその原因がDelphiにあると思ってるが、
例えこの世界にDelphiが存在していなくてもVBはやっぱり
他の言語使いたちから虐げられていただろう。

やはり使っている側の問題が大きいのだろう。だからVB,NETは
もっとシンタックスを複雑にして厨を近づけなくする必要がある。

きっとC++使いやJava使いには心理的に超えられない壁があるんだろう。
Delphi使いは攻撃してもリスクが少ないだろうという彼らなりの計算か。

>>482
本質は言語の問題じゃないYO。
VBは技術的レベルが低くても使える言語だから、他言語使いよりも劣ってると卑下してる。
だからといってVB使いの技術レベルが低いわけではなく、単に技術レベルの低い人達が多いというだけ。
この上のスレの内容がわからないような、VB使いより技術レベルが劣るC++やJava技術者も少なからずいるはず。
このジレンマが論争の火種になってると思う。

Delphi,C++,Javaサイドは、自分達の使ってる言語より劣ってる言語しか使えないVB厨房といい放ち、
VBサイドは、確か言語仕様は他言語に劣る点はあるが、技術力では決して負けてない一部のVB使い。
双方、技術的な会話をできるほど力がないから言葉の揚足ばかりしてる。

もしVBが一般のアルゴリズムを自由に使え、ライブラリも蓄積出来る言語だったとすれば
適性のある人はどんどん先に行って、技術格差が極端に開いてしまう事になったでしょうね。

技術力のある人が使ってもせいぜい数倍しか作業効率が変わらないのがVBの良さでもあり、限界でもあるのでしょう。

OSのスレッド制御とSEHの挙動も知らないような香具師に言語比較論を語る力はないってことか。
言語仕様の比較やコンパイラの生成コードの評価すらできないような香具師には無理だわな。

>>487
それがもっとも正しい解かも。あんた鋭いこというね。

SEHって何よ？

SEHくらい具具れよ。構造化例外処理だろ。
スレッドのような制御オブジェクトの例外を制御するオペレーティングシステムの機構。

低レベルな人たちの声がでかすぎるのが最も問題点。
その大半がＣＯＢＯＬから流れてきた者達である。

Visual Cobol.net
Visual Cobol++
Visual Cobol#

スレの予感…

富士通アメリカが.NET上のCOBOLを提供していたな。COBOLerに.NETは敷居が高すぎるな。

COBOLは勘定系システムにはもっとも適していて必要な言語だけど、確かに高い言語の技術力は必要ないわな。

いやね。マジレスすると

荒らしの人間的レベルは誰が何とも言おうとも　低　い。

>>496
技術的な観点から論理的な話の展開ができないから、
主観の入り込む所や言葉の捉え方をかいつまんで子供でもできる水掛け論をするのだろうな。

要するに本当はプログラミングなんて作業自体好きでは無いのでは？

なんで富士通はCOBOLにこだわるの?

なんで荒らしってVBを極端に嫌うんだろう？
>>482-485あたりにも出ているね。

ＤｅｌとかＶＢって荒らしを呼ぶ言語なんじゃない？

まっ荒らしは厨ってことです。

>>499
メインフレーム残留資産が膨大にあるからなのかな。富士通は以前からずっとCOBOLにこだわってるね。
最近のPCは性能も向上したし、クラスタリングもロードバランシングもできるし、スケールアップからスケールアウトでソリューションが増えたし。
>>500
たぶん自分より下の何かが必要なんだよ。手っ取り早く叩ける対象が必要なんだろう。
実際はもしかしたら技術力がはるかに下なんんだろうけどさ。

言語の違いで荒らしたり荒らされたりするのって変だな、
自分が使ってる言語が最高だと思いたいのは理解できないでもないが、
だからどーしたと言うのだろう、
COBOLでもVBでもCでもDelphi何を使っても、
良いシステムやプログラムを書くことが大切であって、
言語は問題では無いとおもうのだが・・・。
最近、ここも荒らしまくってる奴がいるようだが、
何がいいたいのかよく判らん。

>>504
久しぶりに激しく同意。

VBでも(「でも」っていうのもおかしいが)こういう高度な話題も出来るし、
出来る知識を持った奴もいるわけで。
それについてこれない、認めない奴が荒らすのだろうね。

このスレの主旨に立ち戻って、一つ高速化のネタを。
外部関数コールの高速化について。
APIなどの外部関数のコールは実はダイレクトに呼び出されずにVBのランタイムを経由するけど、これをダイレクトにコールする方法として、
タイプライブラリを使ってそれを参照設定することによってプロトタイプ宣言（つまりDeclare宣言をしない）をするといい。
ただし文字列のポインタ（アドレス）を引数に渡す場合には、暗黙のUnicode-Ansi変換が行われないため
APIなどは関数名の末尾のAとWに注意して利用する必要がある。
これによってランタイムを経由する時間の削減およびUnidode-Ansi変換の時間をなくすことができる。

>>506
ええと、昨夜相手してたのは俺で、俺はVBは嫌いなんだが？

>>508 嵐はだまっとれ。

>>507
タイプライブラリを使っても正確にはDLL関数を直接呼び出してないみたい。
かなりショートカットされて早くはなるけど関数のエントリを呼び出さずにVBランタイムを経由してる。
でも文字列の変換はされないからそれなりに速いか。
検証に利用したAPIはTextOutW。MIDLコンパイラで、/mktyplib203 /win32　オプションでビルドしたタイプライブラリを使った。
ソースは、こんな感じ。

#define WINAPI __stdcall
#define VOID void

[
uuid(FA5FB224-4222-11d2-8137-00C04FB64A56),
helpstring("The 2ch sample, Declare by TypeLib"),
version(1.0)
]

library The2chSample {
[dllname("GDI32.DLL")]
module Win32API_GDI32 {
[
entry("TextOutW"),
helpstring("Boolean TextOutW(long,long,long,String,long)")
]
long WINAPI TextOutW([in] long hDC,
[in] long x,
[in] long y,
[in] BSTR bstrString,
[in] long nCount);
}
}

　　　　 ,へ､　　　　　　　　／＾i
　　　　 | \〉｀ヽ-―ー--<　〈\ |
　　　　 7 　 , -- 、, ---　、　 ヽ
　　　 /　 / 　＼､i, ,ノ　 　 ヽ　 ヽ
　　　 |　 （-=・=- 　-=・=- 　）　　| 　　　　VBスレでIDLまで持ち出しやがって
　　　/　彡　　/ ▼　ヽ　　ミミ　　　、　　　 殺気がにじみ出てるぜ
　　く彡彡　　 _／＼_　　　　ミミミ　ヽ　　　
　　　｀＜　　　 　　　　　　　 　ミミ彳ﾍ 　　
　　　　 　＞　 　　　　　__＿／　　　＼ 　　
　　　　　/　　　　　　　　　7　　　　　　＼ 　
　　　　　|　　　　　　　　／

VBは、同じ処理を行うならFormやクラスのメソッド内にコードを書くより標準モジュール内に書いたほうが高速に動作する。

(ﾟДﾟ)ﾊｧ? 512は妄想VB房の寝言ですか？

やれやれ、ずいぶん香ばしい厨房がいるな
誰か512にコンパイラがどんなものか教えてやれ　（　´,_ゝ`）ﾌﾟｯ

標準モジュールの関数FooBasとFORMのメソッドFooMeの２種類。同じ内容の２つのコードをコンパイルしてコードを見れば一目瞭然。

Function FooMe() As Long
Dim l As Long
l = l + 1
FooMe = l
End Function

Function FooBas() As Long
Dim l As Long
l = l + 1
FooBas = l
End Function

実質的な処理コードは同じだが例外ハンドラ関連処理及び暗黙のオブジェクトのアクセスのためにスタックフレームの形成と破棄のコードによって大きな差がでる。

--------------標準モジュールの場合--------------
4: Function FooBas() As Long
00401F70 mov eax,1
00401F75 ret

--------------FORMの場合--------------
29: Function FooMe() As Long
00401F00 push ebp
00401F01 mov ebp,esp
00401F03 sub esp,0Ch
00401F06 push offset ___vbaExceptHandler (004010e6)
00401F0B mov eax,fs:[00000000]
00401F11 push eax
00401F12 mov dword ptr fs:[0],esp
00401F19 sub esp,10h
00401F1C push ebx
00401F1D push esi
00401F1E push edi
00401F1F mov dword ptr [ebp-0Ch],esp
00401F22 mov dword ptr [ebp-8],offset __imp_@__vbaFreeObj+3Ch (004010c0)
00401F29 xor esi,esi
00401F2B mov dword ptr [ebp-4],esi
00401F2E mov eax,dword ptr [Me]
00401F31 push eax
00401F32 mov ecx,dword ptr [eax]
00401F34 call dword ptr [ecx+4]
00401F37 mov dword ptr [FooMe],esi
30: Dim l As Long
31: l = l + 1

32: FooMe = l
00401F3A mov dword ptr [FooMe],1
33: End Function
00401F41 mov eax,dword ptr [Me]
00401F44 push eax
00401F45 mov edx,dword ptr [eax]
00401F47 call dword ptr [edx+8]
00401F4A mov eax,dword ptr [FooMe]
00401F4D mov ecx,dword ptr [FooMe]
00401F50 mov dword ptr [eax],ecx
00401F52 mov eax,dword ptr [ebp-4]
00401F55 mov ecx,dword ptr [ebp-14h]
00401F58 pop edi
00401F59 pop esi
00401F5A mov dword ptr fs:[0],ecx
00401F61 pop ebx
00401F62 mov esp,ebp
00401F64 pop ebp
00401F65 ret 8

>>513
実際に速いんですけど何か？
>>514
私があなたに教えてあげましょうか？

やれやれ、ずいぶん必死な厨房がいるな
誰か512に教えてやれ　（　´,_ゝ`）ﾌﾟｯ

>>512 good job!

デバッガーも使えない素人相手にそうムキになるなよ

>>518==>>513
>>520==>>514
厨房必死だな(ﾌﾟ

>>512
相手にならない雑魚はほっとけよ。議論にならん

>>521
俺は>>518だが>>513じゃないぞ。
たまたま上がってたスレに必死な奴がいたから書き込んだだけだ。
相当必死なんだな。

そういう煽りはマ板でやれよ。
相手してくれる厨房がくさるほどいるぞ。

>>524
んー。最近マ板行ってる？つまらなくなってるんだけど。
というかム板が荒れてきたからマ板の勢いが無くなってる。
DelスレとかC#スレがすごいことになってるし。

518でも513でもどっちでもいいが、煽るなら根拠を出せ。
語るにはそれに見合う実力が必要なんだよ。

>>526
別にどうでもいいよ。

>>526
コイツ、何でキレてんだ？
相当必死なんだな。

VBの利点はVBAと仲がいいことです。表裏一体といっても良いでしょう。
Officeは実用的高級コンポーネントを持ったVBなんだとも言えます。
但し.NETのVBは毛色が異なります。VB6.0のことを言っています。
MSの立場では、VC++等で書かれたコードは、ソフトウェアというよりも
ハードウェアの調整部分をソフトウェア化したものであると捉えてます。
つまりハードウェアの一部を作っていると考えるのが自然です。
VBやVBAは仕様書にする前のプロトタイプ段階で使用するのが最適で
そもそも速度よりも、気軽に仕様を変更しながらあれこれ試行錯誤して
いくのに適してます。スピードうんぬんはどうでもいいのです。
（書籍でVBによる有限要素法とかありますけど、まとまった量とか長時間に
渡って断続的に何回も計算をするような用途には余り向いていないことは明ら
かです。）にもかかわらず、あれだけのスピードが出たら上出来だと思うべき
でしょう。VBAでは遅すぎるという時にVBを補助的に使うのが良いと思います。
（Excel＋VBAを開発環境とみなすと、変数をすべてセルの上に置けばこれほど良い
環境はありません。）
.NET,Java系はそもそもMSの基本的ポリシーに沿っていないところがあるので、
長期的に使われることを前提とする場合、仕様書代わりにソースを書くという
用途のみに用いるべきです。精々コンテナとして用いる以外は実装はVC++に任
せるべきです。プログラム全体の論理的構成などをきちんと行うことに専念し
コードの最適な分割や速度面などの些末な問題はVC++に任せるべきです。
下手な仕様書よりも、VB.NETやJava,C#等で書かれたソース（動作確認は取って
下さい）を渡されるほうが効率的に決まっています。VC++プログラマが速度面の
向上への配慮や様々なシステム実装上の配慮をそれらに施したものを書くでし
ょう。

VBは大雑把にプログラムの仕様・インターフェースを決めるためのもの
。NET系言語は、論理的構成や論理的不具合、将来の改良・保守に配慮
して清書、VC++プログラマに要求定義する為の通信用言語
VC++はシステムの実情に配慮しながら細部を書いていく言語
時には汎用化できるソフトウェア部品が生まれてVBでも使えたりすることも
期待できる。

VCもVBも使うけど、C++だから誰でもきちんとした細部までの作りこみと速度の最適化ができるわけじゃなく、それだけのスキルがある人ならば可能ってこと。
言語には向き不向きがあるのは理解できるけど、どの言語だからできるとかできないとかじゃなくて、本質的には技術力の問題だと思う。

それにVBとVBAは想定してる利用者も製品の位置づけも違うと思う。
VBAはOfficeをプラットフォームとしてアプリケーション利用者を対象としてるのに対し、VBはプログラマが対象だということをM$は明確に言ってるし。

VBしかしらない香具師は、速いソフトは作れないし、
他の言語も知ってる香具師は、速いソフトがVBでも作れる。

かもしれない？　場合もある？　ま、ちょっと覚悟が必要か？

というか、VC++は細部の記述能力に優れているが、対極的な記述能力や
ソースコードの可読性を保守するなどの能力を失ってしまっているので
.NET系やVB/VBAがそれを補わなければ大きなアプリは作れないってこと
でしょ。VB/VBAで論理的な不具合（存在しない条件を検索しようとした
りとかそういうプログラム以前の問題を排除）を無くし、.NET系の言語
で仕様を実行可能なソースの形で残し、C++でそれを販売する為のコード
に直すって感じ。

実はVB/VBAを使うのは最も高いスキルが必要だったりする。
スキルの上からじゃ案外と
VBA>VB>.NET系言語>C++
だったりする。世間の評価は完全に逆みたいだが。
プログラマ養成段階でVBAからスタートして、C++まで降りて
今度は管理者養成段階でC++からスタートして、VBAまで上がる
ってのがいいんじゃないのか？

>>534
VB6で、でかいもの書く方が無謀だと思うが…
VB.NETならまだしも。

Delphi一本で良いじゃん。

>>535
そうだね。　既出だけど、
熟練しても効率が上がらないのは、熟練するほど、高いスキル＝経験値が必要だったりするあたりにあるよね。

>>536
「でかいもの」の定義によるんじゃね？
世の中の「でかいもの」はCOBOLで書かれてるのが現実だったりする。

>>537
Delphiはね、使い手しだいの面が大きいからね。
直感力・洞察力・そして努力を厭わない事に優れている人が使った時の特性は素晴らしい。
でも、そうじゃない人にはVBと同じだ。　いや、初心者にはVB以下かもしれないね。

下手したら10倍くらいの差が出てしまうような道具は、今の日本の業界（人売的要素）には合わないんだよ。

それよりは、誰がやっても同じ程度の出来（少なくとも見栄えは）、
優秀な人がやってもそんなに効率があがらない特性は
素晴らしく日本にマッチしてるんだよ。

悪いがDelphiは問題外。　もちろん趣味なら個人の勝手だが、業務には使えん。
個人的にはTurboC、TurboPASCALに散々世話になった世代だが、業務ではやっぱMS-Cだった。
某ランドは商売下手すぎだね。　M$が鬼畜なのも分かるけど．．．
業務用途に採用されるには性能だけではダメなのよ。
某ランドはもう少し営業というものを覚えなければならない。

>>541
因みに、俺はVBもDelもMS-Cも用途で使い分けしているのだが、
Delが業務で使えないと思った理由は？
あと、541的にはVBは業務で使えますか？

>>542
業務ってのは複数人で作る事が多い。
複数人でやるプロジェクトは人材がいつでも交換出来る事が必須なのさ。
Delphiじゃ人材の当たり外れも大きいし、そもそも人売り屋で売ってないからな。

まあ総じて日本のＩＴ業界は上を見ても下を見ても駄目駄目なんだが。

確かに今のプロジェクトは複数のチームに分かれて開発するし、１０人くらいを目処チームができてるし、人材の入れ替えが起きるのは確か。
数人で作る小さなプロダクトならいいけど、規模が大きくなるとどうしても人の入れ替えが必要だよね。
人に依存しないように開発時の規約を上流工程も下流工程も統一してやるしさ。個人の能力的な格差はできるとしてもね。
それにDelphiでもVBでもC++でもJavaでも、大規模開発ができないわけじゃないよ。仕様どおりにはみな作れるしさ。
すこし大きめのSIerなら１つのプロジェクトに複数の言語を使うなんてこともよくあって、
ビジネスロジックの核となるコンポーネントはJavaで、クライアントのUIはVBで、クライアントのコアロジックはC++でなんてよく見かけるし。
バックグランドのメインフレームはCOBOLのプログラムで、それと連携するなんてことはざらだし。
でもこのスレでは、こうゆうことを言うのではなく、>>1の言いたいことは処理速度の観点からVBの極限までしゃぶりつくすってことなんだろうな。

>>540
Delだけじゃないよ。ほかの言語も使い手によってすごい差がでるよ。プログラムってそいゆうものなんだろ。

>>545
処理速度アップのネタをだせってか？
それなら、プリミティブなデータタイプでは関数にByRefで引き渡すと高速になるけど、しかしOMコンポーネントを呼び出す場合はByValのほうが高速になるよ。

OMコンポーネント→COMコンポーネント

VB6でもAPIを使えば普通にスレッド使えますが何か？



もっともパラメータ一つ渡すにも大変だったり、
まともにデバッグはできないわ、
同期をうまくやらないと即死だったりするけど…

>>547
おきまりのセリフだが、その根拠は？

スレッドは使えるね。でもスレッド関数の中からオブジェクトにアクセスできねーよ。

>>550
そんなの常識だから聞くな。みっともない。

ドコノ ジョウシキダ？ゴラァ

　　　 　 　 　 　 　 　∩
　　　　 　 　 　　　　 | |
　　　　　　∧＿∧　 | |　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　　　 　（　´Д｀）／/　　＜　先生！>>553は値参照とアドレス参照の違いをしらないことを自慢してます。
　　　　　 ／ 　　　　/　　　　＼＿＿＿＿＿＿＿＿＿
　　　　 / /|　　　　/
　 ＿＿| | .|　　　　|　＿_　
　 ＼　 ￣￣￣￣￣　　 ＼
　　||＼　　　　　　　　　　　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

　　　 　 　 　 　 　 　∩
　　　　 　 　 　　　　 | |
　　　　　　∧＿∧　 | |　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　　　 　（　´Д｀）／/　　＜　先生！>>553はCOMのマーシャリングを知らないことを自慢してます。
　　　　　 ／ 　　　　/　　　　＼＿＿＿＿＿＿＿＿＿
　　　　 / /|　　　　/
　 ＿＿| | .|　　　　|　＿_　
　 ＼　 ￣￣￣￣￣　　 ＼
　　||＼　　　　　　　　　　　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

　　　 　 　 　 　 　 　∩
　　　　 　 　 　　　　 | |
　　　　　　∧＿∧　 | |　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　　　 　（　´Д｀）／/　　＜　先生！>>553はスタンダード呼び出し規約のスタック構造を知らないことを自慢してます。
　　　　　 ／ 　　　　/　　　　＼＿＿＿＿＿＿＿＿＿
　　　　 / /|　　　　/
　 ＿＿| | .|　　　　|　＿_　
　 ＼　 ￣￣￣￣￣　　 ＼
　　||＼　　　　　　　　　　　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

もうそのくらいでヤメレ （藁

スタックの構造は知ってて当然としても、マーシャリングの仕組みを知る香具師は少ないんじゃ？

マシン境界やプロセス境界を越えたりするだけではなくて、同一プロセス内でもスレッド間マーシャリングなんてのもあるし、
明示的なマーシャリングもあれば暗黙のマーシャリングもあるしな。

ﾙｻﾝﾁﾏﾝ

マーシャリングのコストをわかってないとパフォーマンスは出せないでつね。
得にアウトプロセスサーバーのケースと、インプロセス内のスレッド間マーシャリングは大切でつ。

アウトプロセスサーバーはあまり使わないが、マーシャリングのオーバーヘッドは馬鹿にならんな

そうでつね、むしろプロセス内の方が深刻でつね。
しかもアパートメントモデルが異なると暗黙にマーシャラーが暗黙にセットアップされてスレッドのコンテキストが切り替えわるまでの待ち時間が痛いでつ。

VBはあまり気にしなくてもいいんじゃん。
作れるクライアントSTAだし、作れるサーバーもSTAでMTAは作れんしさ。
しかもクライアントはシングルスレッドが基本だから、スレッド間マーシャリングも不要。

>>564
それを知ってて利用するならいいが、知らないでやってると厨房扱いされる。
VBって任意にスレッドを作れんのか。不便っていうかスケールアップのスケーラビ利ティがないんじゃん。

それじゃVBはどうやって、STAで初期化する複数のスレッドを作るんだ？

VBでIEコンポーネント使ったらページ読み込みは非同期でおこなわれる。
ProcessWalkerで調べたら別スレッドになっているようだ。

それはアウトプロセスサーバーで別プロセスのスレッドか、もしくはインプロセスサーバーとした場合でも、サーバー内でスレッドを生成して、スレッド間マーシャリングをしてシンクしてるからだよ。
スレッド間マーシャリングが発生してるから頻繁にシンクが起きるとパフォーマンスが低下するYO。ADOの非同期通知やRDOもでも同じだよね。

VBのクライアントでスレッドを生成して、そのスレッド関数からVBのオブジェクトにコールバックというかシンクさせることってできんの？

>>569
意味不明。

簡単にはできないYO。
VBのプライマリスレッドの管理するオブジェクトを他のスレッドから使うにはスレッド間マーシャリングを明示的にする必要があるから。

ここ、濃密なスレだな

いや、希薄なスレだ

>>1-1000
ばーか

>>574
99.9%誤りだが、0.1%正解のようだ

>>575 ﾜﾛﾀのでage

あんな文で笑える奴がいるとは。自演か？

>>577
自演とわかるレスにあえて突っ込むことなない。
>>573-575
話が理解できなくて嵐をやってるなら、情けないからさっさと消えろ。存在が迷惑だ。

>>578
文盲

576
まあ、どちらかというと漏れは>>574にﾊｹﾞ同なわけだが。ｗ
>・文字列はStringを使用せずに、Byte配列(Cのchar同等)を使用する。
んなことするぐらいなら、用途によって開発環境使い分けろよ。

あと、やけに長文好きなやつが１名生息しているようだが、激しくキモい。
実行不可の話でえんえん知ったかしたあげく、ようやく納得したかと思えば、
今度はメモリアクセスの異常を「PAGE_GUARDの例外」とかｱﾌｫほざいてるし。
しかも誰も指摘してないし。ｗ

VB.NETは(・∀・)ｲｲ!
VB6逝ってよし

> >・文字列はStringを使用せずに、Byte配列(Cのchar同等)を使用する。
> んなことするぐらいなら、用途によって開発環境使い分けろよ。
全部が全部Byte配列を使えってことじゃないでしょ。
パフォーマンスに影響がある部分を局所的にやる。
局所的なことのためだけに開発環境を変えるのもどうかと思うが？

>局所的なことのためだけに開発環境を変えるのもどうかと思うが？

その局所的な部分を別開発環境にしろ。

>>583
馬鹿ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!

>>580
仕方ないと思うよ。そこらへんは普段知らないでいい事だしね。自分も

１、なんとEXEもDLLと同じく毎回同じアドレスにロードされる

２、スタック領域も必ず同じ

３、スタックだろうがデータ領域だろうが　コードとして実行可能
　　これはWindowsがフラットメモリモデルを捨てなければ簡単なガード方法はない

という事で、バッファオーバフローがそのままセキュリティに直結する仕掛けとなっていたってことを最近知ったよ。
そんなもんじゃないの？

なんで、インテルはページ単位に実行不可ビットを作らなかったのかとか、今からでも作れとか
なんでWindowsはフラットモデルにしたのかなあ　とか　今からでもコードだけ別にしたっていいだろとか
せめて、コードを毎回違う位置にロードしろとか、　スタックポインタも毎回初期化位置を変更しろとか

>>585
まーね。普通はそんなもんだとは思う。

多分今さらMSに言っても、.NETなら/GSｵﾌﾟｼｮﾝでおっけーなので移行しろー、
とか、商売に利用されそうだな。あんなもん気休めだろうに。

そういう意味ではVBはセキュリティリスクが少ない!?ｗ

>>580
でかい口聞く割に内容がない。空気を読めよ厨房。

>>580も十分長文。単なる自演のカモルラージュ？ （　´,_ゝ`）ﾌﾟｯ

>>587 内容について触れてたﾔｼの立場は。ｗ
>>588 「長文」ちゅうのは「一行の長さ」についてのことだ。そんぐらい読み取ってくれYo！

で、VBの性能向上について、おまいさんの見解は？

＞「長文」ちゅうのは「一行の長さ」についてのことだ。

ぎゃはははははははは！

>>590
こわれちゃったみたいだな。ｗ
それとも、何かを誤魔化すためのカモルラージュでつか？（・∀・）

で、見解は？

>>591
え、俺部外者なんだけど。

なんだ。失礼しやした。

>「長文」ちゅうのは「一行の長さ」
これは>>580の文脈の中での話ね。辞書的な意味と言っているわけでわない。

VB6でループ組む前にwith使って少しでも速くしようとしてるんだけどさ
ループん中で例外が起きてエラートラップに飛ぶと
そのエラーの他にもend withがねぇだのと文句言われるんだけど
これなんとかならない？

>>594
なるよ。

>>594
無駄な努力をしますね(ﾌﾟ

え、withって速くなるの？

>>594
文句言われないけど？

Private Sub Command1_Click()
On Error GoTo e
Dim i As Long
With Me.Command1
For i = 100 To 0 Step -1
.Caption = 1 / i
Next i
End With
Exit Sub
e:
MsgBox Err.Description
End Sub

>>596
無知？(w

>>597
なる。↑の例みたいにWithを使って参照するものが一つだけなら意味無いけど。

速度を気にして変なコーディングをしなければならないVBって本当に糞だね。

速度を速くするためのアルゴリズムってのは変なコーディングじゃないよ。

>>599
むしろそこまで気にしてコーディングされたプログラムそれなりに優秀と言えるだろう。
世界には動くのが精一杯のＶＢプログラムが山ほど溢れている。

普通に動いているのも多いけどね。

VB以外の奴にも言えるんだけどさ、

char *str = "hogehoge";
for(i=0;i<strlen(str);i++) do();

見たいに書いてる奴は、いただけない。
ちょっとした工夫は大事。

>>603
じゃあ

function hige( s:string;) : integer;
var i:Integer;
begin
　for i:=1 to length(s) do ・・・
　　・・・
end;

とかを見たらどう思う？

>>603
VBの場合は一度しか実行しなかったような

>>605
いかにも。VBでは１回だけだね。

>>605
本当に？ループ内で文字列の長さが
変わる場合があるから最適化なんてできないと思うが。
C/C++もまた然り。

VB の場合はヘルプに end 変数を変更した場合について記述が判りにくいけど
Delphiの場合は、評価は1回だけしかされない。
たとえ、ループ中にサイズが変更されようがループ回数は自動更新されないわけだ。

>>16-17
　ﾜﾛﾀ。

　所詮ＶＢは��Visual <BASIC>�＝A
Visual <Beginner's> All-purpose Symbolic Instruction Codeなんだ。
初心者用のﾌﾟﾛｸﾞﾗﾐﾝｸﾞ言語。
やっぱり、Ｃ++こそ一番。Javaもけっこういい。

クラスとかインターフェース継承とか
ポリモーフィズムとかの概念があっても初心者用なのか。
名前に誤魔化されている奴多過ぎ。
そういう奴って権力に弱そうだなｗ

VBしかできないくせに上級者気取り

○しかできないくせに上級者気取り

○に適当な言葉を入れてあちこちにコピペしている奴がいる。

>>613
どこに？

ここに。

>>611
クラス？VBの「クラスモジュール」のことか？
「ポリモーフィズムの概念」？
意味分かってて言ってんのか？
VBはなかなか便利だから嫌いじゃないが、こういう自分で喋ってることの
意味が分かってないようなヤツが大半占めてるからVBOnlyプログラマは困るねぇ。
ハッキリ言ってVBはまともなオブジェクト指向言語じゃないぞ。

図星か？
>>613=VBしかできないくせに上級者気取りしてるアホ

VB知らないバカが自滅という素晴らしいオチがついたな。
http://homepage1.nifty.com/CavalierLab/lab/vb/clsmdl/polymorphism_02.html
http://www.seraphyware.jp/dev/tips/vb.tips.class.3.html

> VBはまともなオブジェクト指向言語
だれもそんな事言っていない。
準オブジェクト指向言語とは言えるが。

>>613
コピペしかできないくせに上級者気取り

もういいじゃん。さっさと.NETに移行しなさいよ。

>>621
重いじゃん。

今更だがＣで>>1と同じことすりゃいいじゃん。
















と言うわけで終了。

Ｃをもっと早くしたほうが使い勝手がいいんでない？

>>1
VBなんか使わないで普通にＣで速いアプリ作れ。

>j=GetCount(); for(i=0; i<j; i++) などとやる方がいい。


汚いからクソだろ

>>1
最速で挫折

C#で速くてコンパクトで依存性が低いネイティブアプリを作れたら
それが最高なんだが…

VBは依存性高いし言語使用糞だし…

>>628
C#でC/C++に負けないくらいの速いアプリを作ろうスレへどうぞ。
オマエの書いていることは、このスレの趣旨と実質的に同じ。

普通に作っても別にC/C++に負けないくらいの速度出ているんだが。

>>630
要するに大したものを作っていないと。

本物のプログラマはBASICなど書かない。一般に、12歳以上になってBASIC を書くプログラマはいない。

そんなに怒るなよ、630

>>632
プ

ＶＢでＭＰ３エンコーダーを作ろうと思うんだけど、先駆者いる？

>>635
午後のこ〜だDLL使えばいいから、作ろうとも思わないな

そういう問題じゃない。
ＶＢで作るということに意味があるんだよ。
ＶＢ製のエンコーダーってなんかスゲーじゃんかよ、

VBって4,5千行以上のアプリを作ると
リソース節約も含めて言語仕様による
オーバーヘッドが目立つのかも

元来マクロに使われたりする簡易性がウリの言語だし
大規模化とか高速処理の追求は畑違いだと思う。

>>637
そりゃ出来たらスゲーかもね。

凄いというか・・・
Cで書けばポータブルで、一チップマイコンで使ったりも出来るのに。
Cで書けば、例えばDelphiにObjを取り込ませたり出来るのに・・・・

>>638
そんなこと無いよ。VBの遅い原因は標準関数などが
ActiveXになっていることによる関数呼び出しのオーバーヘッドと
文字列がBSTR相当(だっけ？)になっているせいだから。

VBもネイティブコードなんでメモリを処理するだけなら
最適化が違う程度のオーバーヘッドしかない。

>>640
VBで書いてもDelphiにCOMを取り込ませられるだろ。

VB -> vc++ コンパイラをつくれば解決

そんなにDelphiが遅いと思うならここを見れ。
VBなんて初めから候補にも挙がってないがな(　´,_ゝ｀)ﾌﾟｯ

ttp://dada.perl.it/shootout/

某ランドは、フレームワークての？あれが変だから好きじゃない。
基本的に嫌いじゃないけども、気になるから使わないようにしてる。

>>644
itってイタリアのドメイン？

情報化社会には欠かせないドメインだな。

>638
そうだよな。大規模ならやっぱりCOBOLに限るよ

しかし、つくづくアホなスレだなあ

定期的に>>649のような低脳が現れるよな。

JavaがVBより早いってのはGUI以外の計算の話なんかな？
Javaより遅いGUIというのは信じられないが。
NetBeans使ってるけどエミュレータで動かしてるみたいだ。

＞エミュレータで動かしてるみたいだ。

実際VMだし

CPUの速度が今以上に上がれば、高速なアプリなんか苦労して作る必要なんか極端に減るよ。
8Bit、16Bit全盛のころはアセンブリ言語で書くのが普通だったのが、32Bitの高速CPUが出てきたころには
Cなどの高級言語で書くのが一般的になった。
今時、アセンブリ言語でプログラムを組む機会はほとんどない。
このまま、CPUの速度が向上すれば、VM上で動作する言語でほとんどのアプリが作成されるようになるんじゃないの？
要するに、ハードウェアの進歩によって、実行速度よりも、簡単に開発できることが優先されるようになるってこと。

なら次期主役はＶＢ

もういっそのこと、VBでC++も使えるようにしようぜ

（´-｀）.｡oO(なんで>>5のDelphiはProfessionalでないのだろう…？）

Proでなくても最適化されるからだろ。
某はMSみたいなセコいことしてないし

つーか、VB.net がネイティブコードを吐く、マシな速度の言語だったら、似非オブジェクト指向のVB6なんてとっくに捨てていたんだが…

.net Frameworkを入れて嫌な予感が頭をよぎり、
VS.netを入れようとして寒気がして、
IDEを起動してこりゃだめだと感じた。

いくらなんでも重すぎ。

>>658
重すぎって・・・何世代前のパソコン使ってんだよ。

>>655
ｿﾚﾀﾞ!
インラインC萌え

>>659
PC-9801DOですが、なにか問題ありますか？

DOでWindows9x動いてるんですか？
DOで使えるCPUアクセラレータってありましたか？

さぁ、ドゥだっただろう？

>>658
IDEはVB.NETで書かれてないのに、IDEの速度とVB.NETの速度と
結びつけて考えるのか。

>>663
座布団全部没収ですよ

VB厨悲惨だな

つまり、VB厨は惨にあらずということですね。

まぁ、結局お客は早いだけじゃなくって、多少遅くても　バグが無くて使いやすいのを選ぶということは確かだ・・・・

ソフトの微妙な速度も大事だとは思うが
いくら早かろうが客がクソといえばどんなに早くても、アルゴリズムがすごくてもクソっぽ・・・・

適材適所もいいが、臨機応変に何でもできなきゃ生き残っていけないんじゃないかな

age

結局はORACLEのレスポンスタイムが問題なんで気にしない

いつの世も業界のトップを走るのはVBですね

>>638 VBって4,5千行以上のアプリを作ると

って　大きいのですか？

>>638

4,5万行ぐらいでも重くはないけど。。。。。

VB6でコンパイルした物の体感速度は C++で作った物に比べて 3倍くらい遅い程度に感じる。

５千行程度で何をビビってんだか

重いっつーか、VBアプリだと３千〜５千位の規模が妥当かなーって思うけどな。
１万超えたVBソースなんか見たくないや。

>>674
そこまでの規模だったら素直にドトネトにせいと言いたい。


※簡単なアプリを簡単に作る。これがVBの美学だと思われ。

>>676はクラスとか使ってない低能だろうな

規模が大きくなればOOP必須。
だからこそ
>>そこまでの規模だったら素直にドトネトにせいと言いたい。
と書いたつもりだが。


>>677
局所的にクラス化する事はあっても、基本的には標準モジュールで
手続きチックに組んでるよ。

※VB６のクラスモジュールって使いにくいから嫌いだ。
（最近java三昧だったからかな。まあ、低脳なのは認める）

VBのクラスモジュールってもともと、COMで公開するオブジェクトを
作るためのものだからね。javaとかOOPから来た人には奇怪に見えるのも仕方ない。
VBのクラスモジュールにインターフェース継承だけが備わっているのも、
あれはもともと多態性を表現するためというよりかは、バージョンアップ時に
DLL地獄を回避するため、従来のメソッドの引数なんかを変えずにすますための
ものだから。
Class1にFoo(x%)があって、これをFoo(x&)に変えたい、とかいうときに
Class1_V2を作ってそこにFoo(x&)を書いてClass1でImplementする、みたいな。
たまに、インターフェース継承と包含を組み合わせて実装継承をVBで
擬似的に実現してみせてるページとか見るけど、そこまでしてVBでOOPに
こだわるもんでもないとおもう。

以前勤めてた職場で、VBの仕事なのに二言目にはじゃばじゃばじゃばじゃば
文句ばっかり言って仕事にならない奴がいて困ったことがあった。
「javaならこう書ける」「javaと違う」「javaのようにできない」etc。。。
なまじ「クラス」なんて名前が付いてるもんだから、javaと同じことができないと
「間違ってる！」っていうことになるんだろう。
その人、Win32のウィンドウクラスっていう言葉にもいちゃもんつけてた。
「なんでこれをクラスっていうの？おかしいじゃん」って。
おかしいのはお前のjava原理主義じゃないのか。

長々かいちまったよ。すまん

まあVBのクラスモジュールはこんなような用途で使うのが妥当かと。
・構造体と読み／書き関数があるとき、これをクラスに置き換える。
・厳密に型指定されたコレクションを、Collectionを包含して作る。（ヘルプに詳細な説明あり）
・いわゆるグローバル変数を散在させないように、アプリケーションの
　ルートオブジェクトを作り、そのメンバとして集約する。
　（たとえばPublic変数gConnectionStringがあったら、Applicationクラスを作って
　　Application.ConnectionStringプロパティに置き換える。
　もちろんPublia Application As Applicationだけ必要だけど）
・コールバック関数を要求する関数が作れないので、代わりに、
　特定の名前のメソッドを持ったクラスを要求するメソッドを作る。
　ここでインターフェースが役に立つかも。
・WithEventsを利用して、複数のコントロールに書かなきゃいかんイベント処理を１カ所にする。

VBでこういう「まねごと」みたいなのを作ってなれておくと、
ドドネトやjavaに移行するとき楽じゃないのかな。
ぎゃくに、VBやってからOOP言語をかじってからVBを見直すと、VBで出来ること、出来ないこと、
いままでVBについて勘違いしていたことや見えてなかったことなんかが理解できて
おもしろい。
で結局、VBはVBに向いてることだけ作るのがいちばんだと思うよ。>>676に賛同。

誰か、Microsoft Visual Studio.net Academic version2002
を使ってる人はいませんか。

どんな言語で書こうが、ライブラリ呼び出して終わるような処理に遅いも早いもねえよ

そうだ、処理に応じて言語を選ぶべきだ
ランタイムがらみの理由だけで、VBでなくVBAで作られたバッチ処理がある

洒落んならん。インタプリタでバッチ。
ロジックをチューニングしまくったけどまだまだ改善の余地はある

まったく演算部だけでもVBかCで作りたいもんだ

vbなんていらね

VB6で300万要素くらいの電磁界シミュレーションプログラムを作っているんですけど、
VB.NET2003に移植したら3倍くらい遅くなってしまいましたが、そんなもんなんでしょうか？
数値演算の速度は殆ど変わらないか、高速化する場合もあるとどこかで
聞いたような気がするんですけど、VB6の「配列の範囲チェックの削除」
とかの最適化が効いているのかなぁ。

そんなもんCで組めというのはその通りなんですけど、
VBの手軽さから離れられなくて…完全に厨です。

>>685
.NETはネイティブアプリじゃないからな
場合によってはVBのネイティブコンパイルの方が速かったりする

>>685
ngen

>>686,687
ngenは遅さに気づいた時に試してみたんですけど、駄目でしたね。

ttp://www.microsoft.com/japan/msdn/net/general/dotnetperftechs.asp#dotnetperftechs_topic4
には、「前に述べたように、バージョン 1 (v1) の JIT は、コンパイラが行う最適化のほとんどを実行しますし、
次のバージョン (vNext) ではさらに高度な最適化が追加されて、いっそう高速化される予定です。」
と書いてあるから、VB2005Explessで性懲りも無くまた試してみようかと思ってたりしますw

>>685
私はVB使いでないので的外れかもしれませんが、
.NETアプリはメモリーを結構食うので、メモリーが十分にあるか
確認してみるといいかもしれません。

もちょちょちょちょちょぉぉぉぉぉぉぉぉぉ

>>685
VB6の型宣言のまま移植したとか。あんま関係ないか

もちょちょちょちょちょぉぉぉぉぉぉぉぉぉ

>>685
3倍っていくらなんでも遅すぎる気がするんだが。

>>689
メモリは512MBつんでいてタスクマネージャ見る限りメモリ不足には
陥っていないように見えます。

>>691
型はVB6のLongをIntegerに書き換えたくらいですね。

>>693
うーんそうですか・・・

現在アルゴリズム自体を見直しているので2005への移植は
当分先になりそうですけど、他に数値解析プログラム組んでる人
とかがいたら速くなったか遅くなったか聞いてみたいですね。

>>694
VB.NETで計算を早くする方法を探してみたら、偶然685さんの
別の書き込みを発見してしまった・・・(^^

可能性の一つとして、.NETは、もしかすると関数を呼び出す時の
オーバーヘッド（コスト）が大きいのかもしれませんね。
計算の部分をもし関数にして呼び出していたら、forループの中に
直接書き込んで試してみるのはどうでしょう。

あともう一つですが、ちょっとベンチマークを探してみました。
ttp://devnet.developerpipeline.com/documents/s=9856/q=1/cuj0507bruckschlegel/0507bruckschlegel.html
（もう少しわかりやすいのが、どっかにあったはずなんですが・・・）
ここのfigure 12,13を見ると、現状では.NETは行列（配列）の計算やループに
あまり強くない（あまり最適化されない）のかもしれませんね。

それに比較してVB6はきっちり最適化すると、計算はVCに迫れる速度が
出るという話を聞いたことがあります。ですからもし使うなら
まだ.NETにしない方が得策なのかも。

こんにちわ
僕はパソコン初心者の小学生です
VBってなんですか？

>>696
オーストラリアのビールです。
http://www.fosters.com.au/enjoy/beer/victoria_bitter.htm

>>696
お母さんと一緒にお風呂に入ったまま寝なさい

>>696
マジレスするとVisualBasic Micoosoftの出した開発言語
もともとMicirosoft(というかビルゲイツ)はBASICで一山当てて
大きくなったところがあるせいか、かなり力が入っていて
ものすごく普及した。
しかし普及数が多く、とっつきやすいためにレベルの低い
プログラマが多く出たため、ネット上では馬鹿にされる傾向がある

何を思ったか2002年にVB.NETというものに変わり、名前は似ているが
中身はだいぶ違うものに変身した為、現在ちょっと迷走中

Visual Basicは製品名？言語名？

両方。
ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vbcn7/html/vaconProgrammingWithVB.asp

そこまでチューンにさく労力と時間があれば、
C/C++くらい理解出来るはずです。

C#がネイティブを吐ければよかったわけだ

>>702
C/C++/C#って文法がキモッ

Javaは？

>>703
そこでDですよ

>>704
BASIC/VBのがDANZENキモい

なぁみんな　ＶＢＡ　の話してるんだよな？今

>>707
C厨とかC#厨を呼び出す呪文を使ってみたらD厨が釣れた

>>702
いや遊びだろwww

>>699
VB.NET は 無印VBとは全く違うからな
まぁ、JAVAマンセーな奴らを VBに引きずり込みたかったんだろうよ M$は

Javaマンセーな奴らはJ#.NETに引きずり込みます。
VB.NETは関係ありません。

>>J#.NET
J#ってまだあったの？

それをいうのなら、Javaってまだあったの？

>>713
いやそれは無理がある

おいみんな！>>696に正解を教えるのを忘れてるぞ！
ＶＢは任天堂のバーチャルボーイのことです。

>>715
バレーボールってのもありだぞw

ウィルスバスターだろ。

VBよりVC++のほうが性能いいぞ
VBは言語がわからなくても使えるので、初心者でも一流プログラマーになった気になれる。
VC++は命令名が長くて覚えるのが大変。でも、使いこなせばかなりいい。
JAVAはiアプリ作るならかなり使える。
VBは、戦国無双やバイオハザードみたいな完全3Dゲームじゃなければ作れると思う。


VBでもゲームは作れる。でも、企業に入るならC++言語〜VC++言語じゃないのかな？

>>718
( ﾟдﾟ)ﾎﾟｶｰﾝ

VC++ 言語！？

C++よりもJavaの方が優遇されるよ >> 企業

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

速いアプリを作るのは結構だが、VBって速さに拘る物じゃないと思われ
よほど常識外れな作りしなきゃそんなに遅くも無いしさ。
それよりもC/C++で作られてる有能なアプリを超える者を作ろうぜ

VBが速かったらC++厨が死滅しちゃうから遅いことにしといてやれよ

寧ろ。
機械語でベタ打ちすればそれなりに速いコードになると思うがどうか。

市販コンパイラの性能は高い上、ＰＣでは富豪的なコードが許されるから
その程度の線形な改善よりも、アルゴリズムの改善の方が余程利くよ。

むしろポインタが使えないとアルゴリズムに凝れない部分も多いからダメだ

てすと

>>718
おまえ、才能あるな。

即席適当に作るアプリ以外はC/C++の方がいいでしょ
VBでグリグリ苦労して速いコード組むよりC/C++で普通に作りゃいいじゃない
当たり前の事だと思うんだが
なんでVB？ヒマなの？

h

>>726
> むしろポインタが使えないとアルゴリズムに凝れない部分も多いからダメだ
アルゴリズムにポインタはほとんど関係ない。

>>720
マネージドとかCLIとかそういう奴のことを言ってるのかも

>>731
リストとか木構造とか、ポインタないと実装メンドクサイでしょ

>>733
参照使えば普通に実装できるが？

VBでゲーム作ろうとして挫折したヴァカがここにいます。。。

>>723
一般に配布するアプリならともかく
企業システムなら、
アルゴリズムよりDB（SQLチューニング）の方が
重要だからねえ。