5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

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

2 :デフォルトの名無しさん:03/04/14 07:43
Cで作れば済む話じゃん
Cで作れば済む話じゃん

3 :デフォルトの名無しさん:03/04/14 07:52
>>2
まあそうだが、書き方が悪いだけなのにVBは遅いというデマを
真に受けている輩が多いので。

4 :デフォルトの名無しさん:03/04/14 07:56
>>3
それについては同意

5 :デフォルトの名無しさん:03/04/14 08:02
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

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

7 :デフォルトの名無しさん:03/04/14 08:50
>>1
氏ね

8 :デフォルトの名無しさん:03/04/14 08:52
( ´,_ゝ`) VB厨必死だな

9 :デフォルトの名無しさん:03/04/14 09:29
>>3
Srtingを全部Byteだなんて、VBらしくない、悪いコードだよ

10 :デフォルトの名無しさん:03/04/14 09:52
( ´,_ゝ`) VB厨必死だな

11 :デフォルトの名無しさん:03/04/14 09:55
Stringで動作が遅くなるなんてライブラリが悪いんじゃねーの
代替クラスつくれよ 

12 :デフォルトの名無しさん:03/04/14 10:17
そこまでしてVB使う意味あんの?
VBの利点が全部殺されるだけじゃん……

13 :デフォルトの名無しさん:03/04/14 10:28
( ´,_ゝ`) VB厨必死だな

14 :デフォルトの名無しさん:03/04/14 10:36
局所的な高速化を行うのは有効
VCでDLL書くぐらいならVBで高速化したほうがVBらしさを生かせる

15 :デフォルトの名無しさん:03/04/14 10:41
VBの高速化なんて簡単。
技術者のスキルアップして無知を改善するだけ。

16 :デフォルトの名無しさん:03/04/14 10:49
>>13
マジレス。
VB厨は必死じゃないからVB厨って言われるんですよ。


17 :デフォルトの名無しさん:03/04/14 11:25
( ´,_ゝ`) VB厨必死だな

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

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

19 :デフォルトの名無しさん:03/04/14 11:43
>>12
そこまでって、別にたいしたことじゃないじゃん。
VBでも他の言語と同じようにAPI使うんだし。
所詮パフォーマンスとのトレードオフだよ。

20 :デフォルトの名無しさん:03/04/14 11:44
VBが悪いんじゃない
VB厨が悪いんだ

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

21 :デフォルトの名無しさん:03/04/14 11:45
極端な人間がいるな。
別に>>1を絶対守る必要は無いんだよ。
速度が必要な場所だけやる。
他の言語でも当たり前なことがなぜ出来ないんだろうね。

22 :デフォルトの名無しさん:03/04/14 11:50
C言語やっている奴がやりそうな勘違い。

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

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

23 :デフォルトの名無しさん:03/04/14 12:02
つーか、遅いって言っている奴が馬鹿なんだろ?
比較して言っているやついねーし。
いくら遅いって言っても>>5で証明されてるしな。

24 :デフォルトの名無しさん:03/04/14 12:02
>>22
そういう例はVBだけじゃなく、Delphiとかにもある。
しかしCのやり方を踏襲するのも間違いじゃない。
C風のやり方をするのを、下位互換性を考慮すると言う。
用はVBのやり方が通用しない世界もあるってことを知ってれば
良いということ。
但しVBのほうが読みやすいのは間違いない。
VBはVBに向いた世界があるんで、無理してCとかC++とじか
JavaやC#と張り合っても仕方が無いと思うが。

25 :24:03/04/14 12:04
下位互換性==>下位移植性
に訂正。

26 :デフォルトの名無しさん:03/04/14 12:05
>>24
張り合うつもりは無いけどデマは許せないよ。
自分が無知で遅いコード書いてるのに、
言語のせいにしている奴多過ぎ。

27 :デフォルトの名無しさん:03/04/14 12:14
( ´,_ゝ`) VB厨必死だな

28 :デフォルトの名無しさん:03/04/14 12:15
一人よっぽどむかついた奴がいるもよう。

29 :デフォルトの名無しさん:03/04/14 12:23
>>5
> VC++ (Debug)  : 10034
> VC++ (Release) : 9724
> VB (IDE)      : 49992
> VB (P コード)   : 40007
> VB (最適化)   : 9944
> VB (詳細最適化): 9784
> Delphi        : 9854
何気にDelphiが一番遅いかったり。まっ誤差程度だけど。

30 :デフォルトの名無しさん:03/04/14 12:27
つかVBが遅いのは文字列。
あとは何かというとADOだのDAOだの背負ってるからそういう印象があるんでそ。

31 :デフォルトの名無しさん:03/04/14 12:29
>>29
それのソースどこにあるの?

32 :デフォルトの名無しさん:03/04/14 12:32
ちゃんとよめ。

33 :デフォルトの名無しさん:03/04/14 12:36
終了

34 :デフォルトの名無しさん:03/04/14 12:42
Pコードってなぁに?

35 :デフォルトの名無しさん:03/04/14 12:44
>>5のように短いソースでなにがわかるのかと。

36 :デフォルトの名無しさん:03/04/14 12:46
だれか文字列ソートのサンプルプログラム作ってみてくれ。


37 :デフォルトの名無しさん:03/04/14 12:47
sort(a);


38 :デフォルトの名無しさん:03/04/14 12:53
( ´,_ゝ`) VB厨必死だな

39 :デフォルトの名無しさん:03/04/14 13:00
>>5
これはエラストテネスとはいわない。素数列挙してるだけ。

40 :デフォルトの名無しさん:03/04/14 13:06
こういう話題は80年代前半の話題。言語がどれだけ低レベルの
機能を持っているかということが重視された頃の時代の話。
今は確実に逆に向かっているのだが。

41 :デフォルトの名無しさん:03/04/14 13:16
Delphiの最適化は人力(インラインアセンブラ)で行われるのが普通なので
これは公平な競争とはいえませんね

42 :デフォルトの名無しさん:03/04/14 13:23
( ´,_ゝ`) VB厨必死だな

43 :デフォルトの名無しさん:03/04/14 13:24
>>41
おい。(それならC++だってインラインアセンブラで書けばいいじゃん…)

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

44 :デフォルトの名無しさん:03/04/14 13:25
>40
激同。こんなスレポイ。
| ∧_∧ |   |
|( ´∀`)つ ミ |
|/ ⊃  ノ |   |   ◎

45 :デフォルトの名無しさん:03/04/14 13:26
VBは遅い。
あきらめろよ。

46 :デフォルトの名無しさん:03/04/14 13:29
高速化の話は嫌いじゃないが、いきなり他言語と比べるのはいただけない。
やるならVB同士で、違う記述を比較して、
こういう書き方をすればこれくらい速くなる(あるいは遅くなる)、というのを見るべきじゃないか?

47 :デフォルトの名無しさん:03/04/14 13:32
VB的な高速化は>>1で出尽くしてるような……

48 :デフォルトの名無しさん:03/04/14 13:36
>>46
別に比較してもいいと思うけど。

49 :デフォルトの名無しさん:03/04/14 13:38
納期が目の前に迫ってきたら高速化なんて言ってらんないよ(T_T)

50 :デフォルトの名無しさん:03/04/14 13:53
>>48
だってVB厨はVBしか使えないだろ(ワラ
そんな奴らが他言語でかいて比較、なんてやめてくれ。

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

52 :デフォルトの名無しさん:03/04/14 13:58
かといって大量にまわすループの中でプロパティのキャッシュすらしないのはどうかと思うぞ

53 :デフォルトの名無しさん:03/04/14 14:00
( ´,_ゝ`) VB厨必死だな

54 :デフォルトの名無しさん:03/04/14 14:01
>>53
おまえ「必死だな」が言いたかっただけちゃうんかと小一時間(ry

55 :デフォルトの名無しさん:03/04/14 14:08
まあ、ちょっとハイソなVBerを目指すスレってことで

56 :デフォルトの名無しさん:03/04/14 14:28
( ´,_ゝ`) VB厨必死だな 必死だな

57 :デフォルトの名無しさん:03/04/14 14:38
( ´,_ゝ`) VB厨必死だな

58 :デフォルトの名無しさん:03/04/14 14:39
>>47
そう?
まだあるような気がしないでもない。つか、激しく希望。

59 :デフォルトの名無しさん:03/04/14 15:19
( ´,_ゝ`) VB厨必死だな

60 :デフォルトの名無しさん:03/04/14 15:49
( ´,_ゝ`) VB厨必死だな

61 :デフォルトの名無しさん:03/04/14 16:23
おい、誰かVB厨必死だなとか言っている
>>60のような厨を規制しろ!

62 :デフォルトの名無しさん:03/04/14 18:01
何かネタを提供したらどこからかえらい人がきてさっと高速化してくれるかも!

63 :デフォルトの名無しさん:03/04/14 18:43
Cの三項演算子のようなIIf。
これは関数なのでIIf(A,B,C)のA,B,Cがすべて評価される。
これよりもIfを使ったほうが速い。
If A Then B Else C の場合、評価されるのはAとB、もしくはAとC。

64 :デフォルトの名無しさん:03/04/14 19:30
知識が薄くても作れるのがVBの売りなんだから
自身を否定するようなことは言わないように

65 :デフォルトの名無しさん:03/04/14 20:22
ところでc/c++出来る人むけのVB本ってありますか?
必要になりそうでつ・・・

66 :デフォルトの名無しさん:03/04/14 20:43
プログラミング初心者じゃない奴でもこんな事きくのか…

67 :デフォルトの名無しさん:03/04/14 20:54
>>5
VB (詳細最適化): 9784
Delphi        : 9854

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

68 :デフォルトの名無しさん:03/04/14 21:02
VB厨のやったことなど信用できない。
しらないのにやるなといいたい>>5

69 :デフォルトの名無しさん:03/04/14 21:05
比べるならHSPもいれといてくれ

70 :デフォルトの名無しさん:03/04/14 21:07
CもVBもスピードはほとんど変わらない。
スピードは設計とアルゴリズムがすべてです。
しいて言うなら、MMXの方がよっぽど差がつくよ。

71 :デフォルトの名無しさん:03/04/14 21:13
もっと大きいものをつくって比べてほしい。
速度以外の優劣もわかりそう。

72 :デフォルトの名無しさん:03/04/14 21:33
>>70
証明してください

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

73 :デフォルトの名無しさん:03/04/14 21:34
DelはVB.NETにも普通に負けてたしな。

74 :デフォルトの名無しさん:03/04/14 21:40
ヒデブ

75 :デフォルトの名無しさん:03/04/14 21:40
>>5
>漏れは Delphi をよく知らないので改良の余地はあるかも知れぬるぽ。
VBが負ける可能性あり

76 :デフォルトの名無しさん:03/04/14 21:41
くやしかったらやってみろ。>Del厨

77 :75:03/04/14 21:42
ちなみに俺はDelphiなぞ1ミリもできん

78 :デフォルトの名無しさん:03/04/14 21:49
>>43でも書きましたけどさ。

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

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

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

79 :デフォルトの名無しさん:03/04/14 22:25
( ´,_ゝ`) Del厨必死だな

80 :デフォルトの名無しさん:03/04/14 22:31
ネタ振り。

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

81 :デフォルトの名無しさん:03/04/14 22:43
while(*(s++) != 'A')
関数に飛ばした時点で10倍遅い

82 :デフォルトの名無しさん:03/04/14 22:49
そりゃそうだ

83 :デフォルトの名無しさん:03/04/14 22:58
いや、VBスレなんだからBASICの範囲内で…

84 :デフォルトの名無しさん:03/04/14 23:27
何でここまでC#の話が出て来てないの?
VB厨必死だなとか言ってるやつが必死なんじゃないの?
高性能なマシーンを使えばいいんじゃないの?

85 :デフォルトの名無しさん:03/04/14 23:47
VB以外の話がでる方がおかしいと思うが…

86 :デフォルトの名無しさん:03/04/14 23:50
文字が空文字か調べたい場合は、s=""よりもLen(s)の方が速い。
なぜならVBの文字列にはデータ長が埋め込まれているため。

87 :デフォルトの名無しさん:03/04/14 23:50
>>5

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

88 :デフォルトの名無しさん:03/04/14 23:52
だからDelphiの話も止めてくれ…

89 :デフォルトの名無しさん:03/04/14 23:55
>>87
それはアルゴリズムを変化しているからであって、
「Delphiが」ではなく「すべてのものが」速くなるって事。
勘違いせぬように。

90 :デフォルトの名無しさん:03/04/14 23:59
>>89
しかしDelphiだけループカウンタをグローバルにしている事に作為的な物を感じる。

91 :デフォルトの名無しさん:03/04/15 00:01
>>86
ん?OLEのBSTRは、空のときはNULLでもいいので、
仮に言語が""の代入はNULLをセットしてるとしたら、= ""は単なるポインタ比較で良くて、
Lenの方がSysStringLenの呼びだし分遅くならない?

92 :デフォルトの名無しさん:03/04/15 00:07
Caseを使えってあるけど、飛び飛びの値でもそうなの?

93 :デフォルトの名無しさん:03/04/15 00:08
>>90
俺もそう思う。
そこだけ改善してもう一度やってほしい。

94 :デフォルトの名無しさん:03/04/15 00:11
>>89
しかし、アルゴリズムの改善で100倍も速くなるのなら、そもそもテストの意味がないような・・・

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

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

95 :デフォルトの名無しさん:03/04/15 00:13
そもそもはじめに計った奴が
自分の言ってるアルゴリズムを使ってないってのが笑える。

96 :デフォルトの名無しさん:03/04/15 00:14
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

97 ::03/04/15 00:15
行数きついので見ずらいの勘弁

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

98 :92:03/04/15 00:16
(^^;)ゝ

99 :デフォルトの名無しさん:03/04/15 00:23
自信がある奴、>>1のレスを行単位でバブルソートするコードを
言語ごと書いて、実行速度を調べてくれ。

100 :デフォルトの名無しさん:03/04/15 00:23
>>92
ある程度飛び飛びでもなる。
だけどどこかで線引きがあると思う。

101 :デフォルトの名無しさん:03/04/15 00:26
>>99
使えない言語に手だしてまた凡ミスするのはやめてくれよ。

102 :デフォルトの名無しさん:03/04/15 00:30
強いて言えば、
・不要なDebug.Printを取り除く
・数値型は値渡し強制


103 :デフォルトの名無しさん:03/04/15 00:35
どなたか文字列のi番めの文字を調べる>>80>>81以外の(速くなる)方法知りません?

104 :デフォルトの名無しさん:03/04/15 00:57
文字列操作にMid$ステートメントを使うと速い

105 :デフォルトの名無しさん:03/04/15 01:13
>>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

106 :103:03/04/15 01:19
文字列をバイト配列に代入できるのですね…知らなかった。ありがとう

107 :デフォルトの名無しさん:03/04/15 02:44
できる奴はなにを使ってもそこそこの結果を出し、出来ない奴は文句だけ垂れる。
おれ?おれはもちろん後者だよ(w

108 :デフォルトの名無しさん:03/04/15 03:34
と何気に裏の真理を読み取らせようとする107

109 :デフォルトの名無しさん:03/04/15 07:14
Object型やVariant型に入っている型を調べるときTypeNameで
型名を調べる人がいるが、TypeOf 〜 Isを使用したほうが速い。
あるインタフェースを継承しているか調べるときにも使えるしね。

110 :デフォルトの名無しさん:03/04/15 08:19
http://www.k-514.com/
(σ・∀・)σ 娘です
http://www.k-514.com/img1.html

111 :デフォルトの名無しさん:03/04/15 09:38
高速化の一環として、
 Paintイベントを使用するとオブジェクト全体の再描画が必要なので
 サブクラス化してWM_PAINTに反応して必要分だけ再描画する
とかあげてもいいの?

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

112 :デフォルトの名無しさん:03/04/15 12:29
正直、VBの遅さをAPI等でカバーする事考え始めたら、VBは卒業した方がよい。


113 :デフォルトの名無しさん:03/04/15 12:34
>>105
「For i = 1 To Len(longtext)」
ループ内でlongtextの長さが変更されないのならば、
ループの前でLen(longtext)を変数に代入しておけばよいのでは?

114 :デフォルトの名無しさん:03/04/15 12:42
>>113
>>22

115 :デフォルトの名無しさん:03/04/15 12:42
ListBox(等)に多量のデータを入れる場合、一度Visible=Falseにしてから入れたほうが速い。

116 :デフォルトの名無しさん:03/04/15 12:46
>>112
半分同意だけど、VBはAPIを使うものではないというのは頭が固いよ。

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

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

117 :デフォルトの名無しさん:03/04/15 13:00
VBは遅い。

118 :デフォルトの名無しさん:03/04/15 13:03
>>116
>VBはAPIを使うものではないというのは頭が固いよ。
誰もそんな事は意っていないようですが。莫迦ですか?

119 :デフォルトの名無しさん:03/04/15 13:04
>>118
>>112はもちろん言って無いけど、そう言うやつがちらほらいるんだよ。

120 :デフォルトの名無しさん:03/04/15 13:07
誰に向かって物を言ってるのかはっきりしろよ。

121 :デフォルトの名無しさん:03/04/15 13:07
>>120
おまえがな。

122 :デフォルトの名無しさん:03/04/15 13:50
流れで分かるときはいいだろ

123 :ああああああああ:03/04/15 14:27
そうでもない

124 :デフォルトの名無しさん:03/04/15 16:10
>>102
>・数値型は値渡し強制

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

125 :デフォルトの名無しさん:03/04/15 16:28
VBって遅いの?コンパイラ言語になったんじゃないの?

126 :デフォルトの名無しさん:03/04/15 16:44
>>125
VB5が出たときにみんな期待したんだけど
どの雑誌だかでテストしてガカーリということだった

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

127 :デフォルトの名無しさん:03/04/15 16:50
>>126
へ〜そうなんだ。
そろそろVCの他にもなんか言語覚えようかなあと思ってたけどイマイチなのかなVBって。

128 :デフォルトの名無しさん:03/04/15 16:51
所詮単純な演算ってたいした量をこなさないことが多い。

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

129 :デフォルトの名無しさん:03/04/15 16:59
>>127
とてもVCが使える人間とは思えないな。
その口調。

130 :デフォルトの名無しさん:03/04/15 18:46
よく、VBには出来ないことがあるのでVCを使う
何が出来ないの?


131 :デフォルトの名無しさん:03/04/15 18:50
DLLが作れない(ActiveXDLL除く)

132 :デフォルトの名無しさん:03/04/15 19:38
>>131
リンカをいじくれば、作れるという罠。


133 :デフォルトの名無しさん:03/04/15 19:41
VB.NETならDLLが作れるだろ。

134 :デフォルトの名無しさん:03/04/15 19:54
VBとjava、どっちが良いですか

135 :デフォルトの名無しさん:03/04/15 20:03
それだったらVB

136 :131:03/04/15 20:25
>>132
その手があったか!
リンカ弄りはヘッダ縮小化で経験済みだったのに気づかなかったよ ありがd

137 :デフォルトの名無しさん:03/04/15 20:25
>>1 には非常に効果のある最も大事なものが欠けている。

138 :デフォルトの名無しさん:03/04/15 21:08
それは・・・・・・

139 :デフォルトの名無しさん:03/04/15 21:49
結局、VCで出来ることはVBでも出来るってことね!
 わたし、VBしか知らないんです。

140 :デフォルトの名無しさん:03/04/15 21:55
>>139
VCの場合、ちまたにあるC/C++の資産をそのまま使える事、
そして何より、そのコードからテクニックやアイデア、思考方法を学べる
事が一番大きい事でしょうね

141 :デフォルトの名無しさん:03/04/15 21:56
( ´ー`)y-~~.。oO(下手な釣りだな…)

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

143 :デフォルトの名無しさん:03/04/15 22:01
>>142
買ったコンポーネントにはコードはついていませんでした。
どうやってちまたにあるコードを手にいれるか教えて下さい。



144 :デフォルトの名無しさん:03/04/15 22:05
139で〜す。  
 140,142さん、わかりました。
  ありがとう・・・・・

145 :デフォルトの名無しさん:03/04/15 22:22
VBなんて使うなに一票。

146 :デフォルトの名無しさん:03/04/15 22:24
なんでこのスレアンチが逆宣伝しまくってるんだ?
スレ違いだろ。そんなに真実を語られるのが怖いのか?

147 :デフォルトの名無しさん:03/04/15 22:26
( ´,_ゝ`) VB厨必死だな

148 :デフォルトの名無しさん:03/04/15 22:29
つーか、>>5でVBは他と同じくらい速いって
証明されているわけで、何を言われても
負け犬の遠ぼえにしか聞こえんわけだが。

149 :デフォルトの名無しさん:03/04/15 22:29
>>147
必死で悪いか!
ばーか。

150 :デフォルトの名無しさん:03/04/15 22:30
>>148
あふぉですか?
あふぉですね。

151 :デフォルトの名無しさん:03/04/15 22:30
VCの知ったかぶり 必死だな。

152 :デフォルトの名無しさん:03/04/15 22:32
フォームやコントロールを使うのはVBの方が楽とか言うよねん。

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

154 :デフォルトの名無しさん:03/04/15 22:34
C++を使いこなせる者は、VBを馬鹿にしない。


155 :デフォルトの名無しさん:03/04/15 22:34
OLEを使うのもVBが楽。なのにアーリーバインディングしろ言う1は猫の糞

156 :デフォルトの名無しさん:03/04/15 22:35
http://www2.leverage.jp/start/

157 :デフォルトの名無しさん:03/04/15 22:36
>>155
おいおい。アーリーバインディングでもOLEはOLEだろ?
なに言ってんだか。

158 :デフォルトの名無しさん:03/04/15 22:37
あの程度のコードでネイティブバイナリはいて、差が見えて遅くする方が難しい。

159 :デフォルトの名無しさん:03/04/15 22:38
>>154
インディアン研究家である俺の探求心をくすぐったぜ。

160 :デフォルトの名無しさん:03/04/15 22:39
いくら言っても証拠がなけりゃ証拠があるものを覆すことはできんて。

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

162 :デフォルトの名無しさん:03/04/15 22:45
>>161
別にアーリーでも開発は楽だろ。どちらにしろHRESULTはいらんわけだし。
もしかして参照設定が手間だというのか?
間違った型を入れようとしたらエラーになるし、コード補完も利用できるし。
むしろ逆にアーリーの方が開発が楽だと思うが。


163 :デフォルトの名無しさん:03/04/15 22:48
>>160
ループ変数をグローバル変数にし、
エラトステネスのふるいを勘違いしてる奴を信用しろと?
ひとつだけの偏った結果で全てを判断しろと?

164 :デフォルトの名無しさん:03/04/15 22:51
限られた予算でシステムを組む、VBになるな。

165 :デフォルトの名無しさん:03/04/15 22:52
>>163
じゃあ二つ目の結果を出したら?
結果がなけりゃ所詮口だけだよ。

166 :デフォルトの名無しさん:03/04/15 22:55
>>165
わたしが馬鹿でした…

167 :デフォルトの名無しさん:03/04/15 22:57
>>166
別に馬鹿とかどうでもいいよ。
結果に基づいた反論が出たほうが面白いんだけどね。
まあそれが出るまでは>>5が有効と。

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

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

169 :デフォルトの名無しさん:03/04/15 23:09
>>168
意味わからん。具体的にアーリーならどうでレイトならどうなるから嫌だと?
あんたが勘違いしているだけじゃないのか?

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

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

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

171 :デフォルトの名無しさん:03/04/15 23:20
もうDelphiの話はいいよ…

172 :デフォルトの名無しさん:03/04/15 23:22
>>170
Delphi知らんのだが>>5はローカル変数じゃないのか?

173 :155:03/04/15 23:22
>>169
うーん。なんか俺の食わず嫌いだったかも。まあ趣味グラマなんで勘弁してくれ。

174 :デフォルトの名無しさん:03/04/15 23:23
>>169
オブジェクトが複数のインターフェースを持っている時、
いちいち別の型の変数にQueryInterfaceして、Releaseも個別にやらないといけないのが嫌なのでは?

175 :デフォルトの名無しさん:03/04/15 23:23
思ったのですがこのスレはVBで組まれたアプリのパフォーマンスを向上させるための技術を話すスレですよね?

176 :163:03/04/15 23:23
いつのまにか馬鹿になってた俺…
>>5が確かな情報でないことがいいたかっただけ。

177 :デフォルトの名無しさん:03/04/15 23:33
どうでもいい。
本題に戻りませう。

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

179 :デフォルトの名無しさん:03/04/15 23:42
VBのANDやORはショートカット演算子ではないので、
(結果が決まった時点で後の評価をおこなわない)
If A And B Thenとするよりも、
If A Then If B Thenとするほうが速いです。


180 :デフォルトの名無しさん:03/04/15 23:42
MSがアーリーとレイトの2種類を用意した真意を読み取ろうよ。

181 :デフォルトの名無しさん:03/04/15 23:44
>>179
処理部を2度書けってか?

182 :デフォルトの名無しさん:03/04/15 23:46
>>181 一度で書けよ。

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

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

184 :デフォルトの名無しさん:03/04/15 23:55
>>182
スマンが教えてくれ。どうやって?

185 :デフォルトの名無しさん:03/04/15 23:59
>>183
ライブラリも何かしらの言語で書かれているものですけど?

186 :デフォルトの名無しさん:03/04/16 00:03
>>185
そりゃそーだ。でもライブラリは言語の持つ思想を重視して作られるから
言語毎に特色ある作りになるでしょ?そこに差が生まれる。

187 :デフォルトの名無しさん:03/04/16 00:04
結局コンパイラの性能なんでないの?

188 :デフォルトの名無しさん:03/04/16 00:06
市販のライブラリ == 他人のふんどし
自作のライブラリ == 汚れたふんどし

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

189 :デフォルトの名無しさん:03/04/16 00:11
( `Д)  
/(ヘ っ )ヘ


190 :デフォルトの名無しさん:03/04/16 00:11
追記。実生活でもそうです。

191 :デフォルトの名無しさん:03/04/16 00:11
オレはブリーフ派

192 :デフォルトの名無しさん:03/04/16 00:16
>>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はどうするかって?
工夫すればできるだろ。
予備知識としてドモルガンの法則でも調べとけ。

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

193 :デフォルトの名無しさん:03/04/16 00:18
>>188
市販のライブラリ == 市販のふんどし
自作のライブラリ == 自作のふんどし
の間違いだろ?

194 :デフォルトの名無しさん:03/04/16 00:20
市販のはサイズが微妙に合わないし自作のはたまにハミチンする
上手い例えだな

195 :188:03/04/16 00:21
>>193
いや、間違いではない。

196 :デフォルトの名無しさん:03/04/16 00:22
たとえはたとえであって正解はありえないよ。

197 :デフォルトの名無しさん:03/04/16 00:23
グンゼなめんな。

198 :デフォルトの名無しさん:03/04/16 00:23
>(結果が決まった時点で後の評価をおこなわない)

>ショートカット演算子ではない
の説明じゃなくて
>ショートカット演算子
の説明だったのね

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

199 :デフォルトの名無しさん:03/04/16 00:26
速いとかどうでもいいんだよ。中身だ。中身。

200 :デフォルトの名無しさん:03/04/16 00:26
>>192
そんなコードを書くぐらいなら、喜んでパフォーマンスを犠牲にする。

201 :デフォルトの名無しさん:03/04/16 00:27
>>192
それ本当に速くなってるの?

202 :デフォルトの名無しさん:03/04/16 00:31
>>201
Aが真の場合は変わらず。Aを先にもってくるかBを先にもってくるかの判断は
>>192が統計的手法を駆使して決定している(w

203 :デフォルトの名無しさん:03/04/16 00:42
>>202
それ当然の話だし。C言語でもどちらを先に持ってくるか考えるよ。

204 :デフォルトの名無しさん:03/04/16 00:44
いや、CPUによっては遅くなってんじゃねーの?って話

205 :デフォルトの名無しさん:03/04/16 00:46
>>204
またずいぶんと深いところに・・・

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

207 :デフォルトの名無しさん:03/04/16 00:48
>>204
なんで? 片方が評価されないことがある分速いでしょ。

208 :デフォルトの名無しさん:03/04/16 00:52
mov eax,0 と xor eax,eax
では、後者の方が早い。

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

209 :デフォルトの名無しさん:03/04/16 08:44
>>208
今では そのアセンブラコードはほぼ同じ負荷だけど、前後のコードで違ってくるよ


210 :デフォルトの名無しさん:03/04/16 09:30
VBが作ってくれる機械語をアセンブラにして見てみたいのですが
どうすればいいですか?
全体をアセンブラにされてもたぶんわからないので関数単位で
どの関数はこういうコードになるっていうのを知りたいです


211 :デフォルトの名無しさん:03/04/16 09:45
>>210
VB.NETですか? それならVS上で関数の先頭でブレークポインタしかければ見えるでしょう
VB6だとちょっと厄介です VCは持っていますか?

212 :デフォルトの名無しさん:03/04/16 10:20
Declareで文字列やユーザ定義型を使うと文字コード変換や再配置が発生して遅くなるとか
データが破壊されたりゴミが紛れ込んだりするとかは既出?

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

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

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


214 :デフォルトの名無しさん:03/04/16 10:30
>>213
たぶん 先頭のSleepはそこでタスク切替をさせて 多少なり測定精度をあげたい為でしょ
ただ、実行時間が何秒とかなら、あんまり意味ないのと、1500もは必要ない


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

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

215 : ◆sZMOg20d0E :03/04/16 10:37
213の続きだが、

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

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

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

Delについては・・・すまん。

216 :デフォルトの名無しさん:03/04/16 10:42
>>215
 よーくコードみないといけない
 ここで、continueは使えない
  gotoを減らす為には、結構複雑な対策が必要になる。

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

217 :デフォルトの名無しさん:03/04/16 10:47
こう書き換えればいい
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++;


218 :デフォルトの名無しさん:03/04/16 10:57
>>216
1/100以下なんてデータはどこにもないけど?

219 :デフォルトの名無しさん:03/04/16 11:19
>>218
じゃあ 実行ファイルを作ったからデータを作ってみて
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/file/1050452299_2/TestCon.exe


220 : ◆sZMOg20d0E :03/04/16 11:34
>>216
失礼、ボーッっとしかソースを眺めていなかった、たしかに continue は使えない。
下の方でも ++ してたのね。

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

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

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

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


221 :デフォルトの名無しさん:03/04/16 11:43
>>220
他言語でも有効な手段を使っても差は縮まらないと思われ。

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

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

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



224 :デフォルトの名無しさん:03/04/16 11:52
>>222
ではソースを
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1050452299&res=2

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


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

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


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

226 :デフォルトの名無しさん:03/04/16 12:30
>>225
答えをマンマ配列ってのはルール違反だろうけど 配列を使って求めるのはアリでしょ

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

227 :デフォルトの名無しさん:03/04/16 12:32
>>218
1/100ってのはDelオナニースレの奴ね。
>>5の奴の結果が1/100になるっていうわけじゃないよ。
アルゴリズムが違うわけだから。

228 :デフォルトの名無しさん:03/04/16 12:56
>>227
でも、結果は同じだよ。

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

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

230 :デフォルトの名無しさん:03/04/16 13:06
>>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

231 :デフォルトの名無しさん:03/04/16 13:51
>>229
コードが大きくなっても、キャッシュヒットの効果は絶大だよ。

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

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

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


232 :デフォルトの名無しさん:03/04/16 14:36
>試しに MaxN= 224737+512って決め打ちでやってみたらどう?

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

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

233 :デフォルトの名無しさん:03/04/16 15:04
まあ、あれだ。 よくいる説教厨のセリフの出番って事だな。

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

234 :デフォルトの名無しさん:03/04/16 16:48
>>232
VBも同じく1/10になってるよ。

235 :デフォルトの名無しさん:03/04/16 18:18
通常の三杯

236 :デフォルトの名無しさん:03/04/17 09:02
さてベンチ厨も去ったことだし、
本来の話題に戻りましょう。

237 :デフォルトの名無しさん:03/04/17 09:09
VBアプリのボトルネックってどこよ?
 起動時のDLL読込
 実行時のライブラリ内の処理
ネイティブコードコンパイルで解決できないのはこの二つ?

238 :デフォルトの名無しさん:03/04/17 09:13
>>237
ボトルネックは、その遅い部分に慣れて遅くて平気な感覚を覚えてしまう所でしょ。


239 :デフォルトの名無しさん:03/04/17 09:19
煽りはいらない。

240 :デフォルトの名無しさん:03/04/17 09:25
VBだけをやる人の一番の問題は、
文字列を、文字+列として扱うべきなのに、文字列として扱ってしまう癖が付いちゃう事だろうな。
たとえば、DelフサギコがVBをやってからか 文字列を文字列として扱うようになって
それをDelphiでやってパフォーマンスが出ないと騒いでた。

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

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


241 :デフォルトの名無しさん:03/04/17 09:29
JavaでいうStringとStringBufferの使い分けみたいなもんだな。

242 :デフォルトの名無しさん:03/04/17 09:30
>>239
いや煽りじゃなくて、
速いアプリが作れるかどうかは、数割の差しかでないコンパイラの差じゃなくて、
速いアルゴリズムを実装出来るかの問題でしょ。
ライブラリ部分(OCX含)に引きずられて、速いアルゴリズムが組めないから結果遅くなってしまうのが真実でしょ。



243 :デフォルトの名無しさん:03/04/17 09:32
しかしまぁなんと必死なことか

244 :デフォルトの名無しさん:03/04/17 09:36
>>243
速いコードを書くにはそれなりに必死に勉強しないとダメだよ。

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

245 :デフォルトの名無しさん:03/04/17 09:36
>>242
>>238といっている事がずいぶん違うが。
始めからそう言っておけば煽りだと思われずにすんだのにね。

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

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

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

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

247 :デフォルトの名無しさん:03/04/17 09:52
カールルイスとベンジョンソンが2人3脚するよりジョイナーが一人で走るほうが足が速いようなもの?

248 :デフォルトの名無しさん:03/04/17 09:53
ライブラリが高速ならどうして遅いものが出来上がるのだろう

249 :デフォルトの名無しさん:03/04/17 09:54
>>246
ライブラリやOCXの構成ってなにを言いたいかわから無いんだが、
OCXやそれと同等のCOMはVB以外にもC++やDelphiでも使え、
実際に多くのところで使われているんだが。

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

250 :デフォルトの名無しさん:03/04/17 09:56
>>248
だから遅いものはできないって結論になるんだけど。
実際に極端に遅いものってないでしょ。

251 :デフォルトの名無しさん:03/04/17 10:07
>>247
巧いね。 

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

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

252 :デフォルトの名無しさん:03/04/17 10:11
>>251
だから思うのが勘違いなんだって。
プログラムにおいて、論理的に理由を
説明できないことは間違いだよ。

253 :デフォルトの名無しさん:03/04/17 10:12
> ニュアンスが判ってもらえなくて残念だ。俺は教師向きじゃないのだろう。言葉で導く事は出来ない。
ただ自分の考えがまとまってなくて、
思い込みだけで発言しているからだろ。

254 :デフォルトの名無しさん:03/04/17 10:17
判った判った。 好きにしろよ。

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

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

255 :デフォルトの名無しさん:03/04/17 10:22
高速なビューアってなにが高速なんだかね。
よくわからないけど、ちまたにあるVB以外で作られている
ビューアと同じ程度の速度にはなるでしょ。
実際は差があるかもしれないけど体感は出来ないよ。
もっとも初心者が作ったらどんな言語でも遅くなるけどね。

256 :デフォルトの名無しさん:03/04/17 10:41
>>255
ちまたにあるVB以外と同じスタイルで作れば同じ速度になる。

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

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

258 :デフォルトの名無しさん:03/04/17 11:11
>>240
VB.NET だと Chars で扱えるから多少マシになるかな

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

259 :デフォルトの名無しさん:03/04/17 11:18
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ごときで使えなくなるテクニックって(藁

260 :デフォルトの名無しさん:03/04/17 11:38
>>256
不思議だ。速いテクニックと遅いテクニック。
速いテクニックを使っているのに遅くなるとは。
そこんとこ論理的に説明してもらいたい。

261 :デフォルトの名無しさん:03/04/17 11:44
>>260
先にアルゴリズムを検討しろって事でしょ。
その前のは、採用可能なアルゴリズムがライブラリによって縛られてしまうからそこが問題だって事でしょ。
それくらいは読み取ってやれよ。

262 :デフォルトの名無しさん:03/04/17 11:47
じゃあ別に速いテクニック使うのに何の問題も無いじゃん。
それから他人のふりすんなって。

263 :デフォルトの名無しさん:03/04/17 12:16
>>262
 そうじゃない。 >>1のいうテクニックに問題があるんだ。

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

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

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


264 :デフォルトの名無しさん:03/04/17 12:19
>>262
読解力なさすぎ。
なんかずれてるな。

265 :デフォルトの名無しさん:03/04/17 12:39
>>263
なにを当たり前の事言ってるの?
それはプログラム全般の話でしょ。
ここはVBのスレだよ。>>1の内容は+αのことでしょ。

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

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

266 :デフォルトの名無しさん:03/04/17 12:46
文盲。

267 :デフォルトの名無しさん:03/04/17 12:53
>>265
 ふう。 俺も教師じゃないからここまでが限界か。

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

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


268 :デフォルトの名無しさん:03/04/17 14:31
> 他の言語で配列の括弧の順番レベルの高速化のテクニックなんて検討もしないよ。
最後にはそこにたどりつくんだけどね。
まだまだだな。


269 :デフォルトの名無しさん:03/04/17 15:07
でもまあ、VBで作れるようなショボイゲームでシェア作家になろうって奴には、このスレも十分役立つさ


270 :山崎渉:03/04/17 15:12
(^^)

271 :デフォルトの名無しさん:03/04/17 18:19
>>269
VBでDirectX使えるし、いいゲームを作るための制限にはならないよ。

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

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

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

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




274 :デフォルトの名無しさん:03/04/17 22:32
VBAの高速化についても語ってほすぃ…


275 :デフォルトの名無しさん:03/04/18 08:28
>>274
お決まりだが、処理するときに非表示する。
何の話だったか忘れたけど。

276 :デフォルトの名無しさん:03/04/18 08:31
>>274
 出来るだけコードを書かない。

277 :デフォルトの名無しさん:03/04/18 09:23
つーか、今更VBで環境依存なテクニックなんか調査してどーすんの?

278 :デフォルトの名無しさん:03/04/18 09:30
VBは文字列がある意味ガンで、文字列を使う以上はそれで良しとするしかない。
といっても文字列を使わないようなアプリにVBは最初から不適合。

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

279 :デフォルトの名無しさん:03/04/18 09:35
Delphiなら文字列は配列として扱えるし、他の要素もプリミティブな部分から操作出来る。
VB.NET なら文字列の扱いは改善されてる。

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


280 :デフォルトの名無しさん:03/04/18 09:40
> 構文解析/オートマトン/状態遷移 とかをキーワードに勉強して、

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

281 :デフォルトの名無しさん:03/04/18 09:41
>>278
> 文字列を使わないようなアプリにVBは最初から不適合。
結局自分基準で制限を作って不適合っていっているのと同じじゃん。
文字列として扱うか、文字の列として扱うか。適切なのを選べよ。


282 :K仲川(^^)g:03/04/18 09:48
(^^)

283 :デフォルトの名無しさん:03/04/18 09:50
>>280
低レベルでって事は、プリミティブな部分からアルゴリズムを考慮して作る事を言うんだよ
低レベルで高速化って言うならまず、アルゴリズムやれや



284 :デフォルトの名無しさん:03/04/18 10:13
>>283
コンピュータ用語の「低レベル」の意味を調べましょう。

285 :デフォルトの名無しさん:03/04/18 10:57
いずれにせよ

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

らしいし。

286 :デフォルトの名無しさん:03/04/18 11:57
>>2
で結論が出てるじゃない。 C のような事がしたいなら Cで書くべし。

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

287 :デフォルトの名無しさん:03/04/18 13:45
> そろそろ Cで #define begin { マクロ書くのと同じくらいアホな事やってる事に気付け。
なんでそういう自分基準でわけのわからないこというかなぁ。
はっきり言って全然違う。


288 :デフォルトの名無しさん:03/04/18 18:48
じゃ、こういう問題をどう解決する?

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


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


289 :デフォルトの名無しさん:03/04/18 19:49
つまらんことやってるな。
こんなことを考えなくてはならんほど遅いコードしかかけんのか?

290 :デフォルトの名無しさん:03/04/18 20:08
かけんのさヽ(´ー`)ノ

291 :デフォルトの名無しさん:03/04/19 13:01
そもそも2万個程度の素数を計算させるということがどれだけ比較対象に
ならないかを知らない奴らが痛い。

292 :デフォルトの名無しさん:03/04/19 13:44
じゃあ1千万個程度の素数を計算させてみたらどう?

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

293 :デフォルトの名無しさん:03/04/19 15:13
素数を数えて落ち着くんだ…!!

294 :デフォルトの名無しさん:03/04/19 22:16
お題:1億以下の素数列挙(1200万個くらい?)

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

295 :山崎渉:03/04/20 03:00
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

296 :山崎渉:03/04/20 03:39
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

297 :デフォルトの名無しさん:03/04/21 09:47
>>291,292,294

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

298 :デフォルトの名無しさん:03/04/21 14:35
>>297
おまえさ、もう少し大人になろうぜ。

299 :297:03/04/21 15:32
スマソ


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

300 :デフォルトの名無しさん:03/04/21 15:52
ポインタ関連で、クラスへの参照で代替できないもの、かな…えーと…
固定サイズのオブジェクトを大量に必要とする時allocatorを自前で用意するとか?

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

301 :デフォルトの名無しさん:03/04/21 16:17
charならByteで代用できないかな?

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

302 :デフォルトの名無しさん:03/04/21 16:26
リンクリストや木構造は、配列とインデックスで代替するのと、クラスで代替するのとでは
どちらが速いんだろう?

303 :デフォルトの名無しさん:03/04/21 16:34
配列の場合 Redim Preserve は結構遅くなる


304 :デフォルトの名無しさん:03/04/22 03:50
>>301
文字列がUnicodeだからByteじゃなく16bitが欲しいね

305 :デフォルトの名無しさん:03/04/22 04:35
>>299
ポインタが使えないと、ソートさせるのも一苦労

306 :デフォルトの名無しさん:03/04/22 13:04
>>305
配列のインデックスを格納する配列を用意するといいよ。


307 :デフォルトの名無しさん:03/04/22 21:03
どうも頭が固い奴がいるな。

308 :デフォルトの名無しさん:03/04/22 21:07
ポインタ無くてもクイックソートができないだけなんじゃないの?
バブルソートしか使ったこと無いけどさ

309 :デフォルトの名無しさん:03/04/22 21:18
>>308
んなわきゃない。クイックソートは、たとえ再帰が出来なくて
ローカル変数すらない言語でも実現できる。
もちろんVBはどちらもできるので普通に実現できる。

310 :デフォルトの名無しさん:03/04/22 21:27
VBで作ったソフトをLZHで配布するのに、
COMDLG32.OCXとMSVBVM60.DLLとVB6JP.DLLをLZHに詰め込んで配布したらまずいでしょうか?
ソフトの種類は、シェアウェアソフトです。

311 :デフォルトの名無しさん:03/04/22 21:39
>>310
ファイルサイズでかすぎ。糞。

312 :デフォルトの名無しさん:03/04/22 21:41
>>308
 違うよ。 バブルソートでも同じだけど、それだと中身=インスタンスの交換になるでしょ。
 ポインタでソートすれば、ポインタだけのソートだけら インスタンスサイズ÷ポインタサイズだけ速くなる

313 :デフォルトの名無しさん:03/04/22 21:43
答えないで煽る。最低だな。

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

314 :デフォルトの名無しさん:03/04/22 21:47
ヽ(^^ ) ヨシヨシ

315 :デフォルトの名無しさん:03/04/22 21:55
>>308
よっ!さすがVB厨。

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

317 :デフォルトの名無しさん:03/04/22 22:04
VB厨じゃないのに煽られた・・・。

318 :デフォルトの名無しさん:03/04/22 22:07
>bit数を減らせるのでポインタより速くなる可能性もあります。
遅くなる可能性では?


319 :デフォルトの名無しさん:03/04/22 22:07
>>312
よっ!さすがVB厨。

320 :デフォルトの名無しさん:03/04/22 22:10
>>317
馬鹿には変わりない。

321 :デフォルトの名無しさん:03/04/22 22:12
>>318
キャッシュに入る確率が上がるので
速くなるでしょう。

322 :310:03/04/22 22:26
ありがとうございます。
問題ないことが分かりました。

323 :デフォルトの名無しさん:03/04/23 00:35
32BitCPUでは32Bit型同士の演算が一番速いとだけ言っておく。

324 :デフォルトの名無しさん:03/04/23 02:11
少なくとも同じアルゴリズムだったらVBよりもC++(C)の方が圧倒的に速いよ。
だからといってVBが糞とは全く思わないけども。

325 :デフォルトの名無しさん:03/04/23 02:18
少なくとも同じアルゴリズムだったらVBよりもDelphiの方が圧倒的に速いよ。
だからVBは糞だと思う。

326 :動画直リン:03/04/23 02:20
http://homepage.mac.com/hitomi18/

327 :デフォルトの名無しさん:03/04/23 02:27
ヾ(゜▽、゜)ノ パトリシア……

328 :デフォルトの名無しさん:03/04/23 02:30
この板の釣厨たちを見ていると
「デジドカ」の意味がよくわかる。

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

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

330 :デフォルトの名無しさん:03/04/23 08:27
>>329
 その助言は何10回となされたのだが、受け入れられないのだ。

331 :デフォルトの名無しさん:03/04/23 08:30
>>316
 もしかして 構造体配列を作って、その配列index配列を作ってソートしますか?
 となると、構造体毎にソートアルゴリズムを書かなければならなくなりますね。
 そういやコールバック無かったか

332 :デフォルトの名無しさん:03/04/23 09:29
>>329
結局VC/Delphiには勝てないとわかった上で
どこまで高速化できるかを楽しむためのスレにしようと言う話が少し前にでていたような気がする。

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

333 :デフォルトの名無しさん:03/04/23 09:42
>>332
プログラミングで高速化というのは、あくまでもアルゴリズム改善の事であると判った上で
の話なんだね? 
 そういう事なら、課題を考えて、それをどうするかという方向の方がいいんじゃないの?

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



334 :デフォルトの名無しさん:03/04/23 09:47
VBが遅いのはプログラマの技量が低いのが最大の要因、と何度もガイシュツだが、
何かと話題をVB vs Del(C++)にすり替えたいらしいアフォが多いのでな。

335 :デフォルトの名無しさん:03/04/23 10:09
>>331
なんで構造体ごとに配列index配列のソートを作らなきゃならんのよ?
中身のソートとポインタ(配列index配列)のソートの区別ついてないだろ。

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

336 :332=299他:03/04/23 10:30
>>333
もちろん。そのためのネタフリを何度かしている。
下手に課題からベンチマークで速度を測ろうとするとVC厨・Del厨が暴れそうなのもいやなんだよね。

所詮カートはF1より遅い。
けどカートの最速を求めるのは悪くないよね。

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

337 :デフォルトの名無しさん:03/04/23 10:55
じゃあ x,y,z 座標を持つ構造体配列を作って z 順に描画させるという課題でどう?


338 :デフォルトの名無しさん:03/04/23 11:10
>>335
 比較関数をどうやって渡すんだ?

339 :デフォルトの名無しさん:03/04/23 11:21
クラスで渡せってのは、このスレではダメなのか?

340 :デフォルトの名無しさん:03/04/23 12:40
アルゴリズムで高速化うんぬんならわざわざVBに話を限定することは
ないだろよ。

341 :デフォルトの名無しさん:03/04/23 13:30
>>340
それは違うな。
CやPascalスタイルで開発されてきた普通のアルゴリズムを利用出来ないからこそVBは遅いんだ。
だから、VBで高速化したいなら、普通じゃないアルゴリズムを開発する必要があるって事だ。

342 :デフォルトの名無しさん:03/04/23 13:44
>>337
ソートより描画がボトルネックになりそうな予感

>>341
97%程同意

343 :デフォルトの名無しさん:03/04/23 14:27
>>338
ちっとはオブジェクト指向プログラミングを勉強しろ。

344 :デフォルトの名無しさん:03/04/23 14:32
>>341
> CやPascalスタイルで開発されてきた普通のアルゴリズムを利用出来ないからこそ
利用できないアルゴリズムってなんだ?
ソースが利用できないってなら分かるが。

345 :デフォルトの名無しさん:03/04/23 14:40
>>337 の課題の更新

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

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

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





346 :デフォルトの名無しさん:03/04/23 14:42
反射について、
1、ボールの入る箱を大きな球として
2、正方形として
 好きな方で反射するものとしてよい。

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



347 :デフォルトの名無しさん:03/04/23 14:43
宿題は自分でしろ。

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


349 :デフォルトの名無しさん:03/04/23 15:58
>>347
実際に実装しなくていいんだよ。 VBならこういう実装するという議論が出来ればそれで

350 :デフォルトの名無しさん:03/04/23 17:51
つまり勘違いしたやつがスレ立てて、勘違いした奴らがあつまって、
煽りに対して、いいわけしてる内にわけのわからんことになってると。

351 :デフォルトの名無しさん:03/04/24 14:50
スレ主は自分の言いたいこと分かってるし、
レスしてる人間も分かってる。

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

352 :デフォルトの名無しさん:03/04/24 16:16
ここまで議論の流れ

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)


353 :デフォルトの名無しさん:03/04/24 16:35
その他ご意見:
文字列を値渡しするな。
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に対して)


354 :デフォルトの名無しさん:03/04/24 20:43
初心の頃に VB 最適化 とか VB 高速化 でぐぐったものだ

355 :デフォルトの名無しさん:03/04/29 20:49
age

356 :デフォルトの名無しさん:03/04/29 21:12
>表示中のコントロールの変更の時は、再描画を停止する/非表示にする。(>>115)

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


357 :デフォルトの名無しさん:03/04/30 06:50
>>356 他の言語も使えるのに、やってなかったのか?

358 :デフォルトの名無しさん:03/04/30 16:54
でも処理の都合でリストビューのオブジェクトが急に消えたらユーザーがビックリするのでは?

359 :デフォルトの名無しさん:03/04/30 17:01
停止するだけで十分

360 :デフォルトの名無しさん:03/05/01 16:23
>>358
画面更新してなきゃ表示されたまま。

361 :デフォルトの名無しさん:03/05/01 16:43
DGCAの描画が遅いのはそれが原因か>>115

362 :デフォルトの名無しさん:03/05/01 18:43
DelphiならTListView.BeginUpdate、EndUpdateでお仕舞いなんだよな。

363 :デフォルトの名無しさん:03/05/01 20:23
VB.NETもBeginUpdateでいいね。

364 :デフォルトの名無しさん:03/05/01 20:28
C++BuilderもBeginUpdate


365 :デフォルトの名無しさん:03/05/01 22:15
VB.NETを使えばC/C++に負けないよ。

366 :デフォルトの名無しさん:03/05/01 22:55
>>365
なんで.NETアプリはあんなに起動が遅くメモリを大量に消費するのですか?

367 :デフォルトの名無しさん:03/05/01 23:03
仕様です

368 :デフォルトの名無しさん:03/05/01 23:13
>>367
嫌な仕様ですね。致命的です。

369 :デフォルトの名無しさん:03/05/01 23:26
ってか嘘だし。

370 :デフォルトの名無しさん:03/05/02 01:26
ということにしたいのですね。

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

372 :デフォルトの名無しさん:03/05/02 11:25
>>371
何を言いたいのかサッパーわからん。

373 :デフォルトの名無しさん:03/05/02 11:43
翻訳開始:

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

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

翻訳終了

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

374 :デフォルトの名無しさん:03/05/03 09:51
なんで、そこまでしてVB使いたいのかと。

375 :デフォルトの名無しさん:03/05/03 12:18
そういう傾向があるんだよ。
basicだと簡単な事が簡単に出来る。
で、入門書も、キーボード操作から教えてくれてて、
なんか作れた気分になる。
だから、もっと大事な筈の基礎をはしょってしまってる。

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

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


376 :デフォルトの名無しさん:03/05/03 15:28
ほんとに速いアプリが書きたいなら

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

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

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

377 :デフォルトの名無しさん:03/05/04 11:17
構造化する時に一番大事な事は 命名する事

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

378 :デフォルトの名無しさん:03/05/04 16:27
>>375
別に VB に限ったことじゃないじゃん。

379 :デフォルトの名無しさん:03/05/04 21:45
>>378
 他の言語は、いきなり型とか何とかで適性ないと躓くからなあ

380 :デフォルトの名無しさん:03/05/04 22:01
>>379
でも...
>適性ないと
と言うことであれば、早めに躓いた方が本人のためだよね。

381 :デフォルトの名無しさん:03/05/11 18:27
定期あげ

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

383 :デフォルトの名無しさん:03/05/11 22:21
>>382
そのデータベース化って
普通に言うDBを使うとかじゃなくって
処理に時間のかかる関数の結果をあらかじめ用意してしまうという方のでしか?

384 :デフォルトの名無しさん:03/05/11 22:27
>>383
概ねその通りですね。

385 :デフォルトの名無しさん:03/05/12 14:24
ハードウェアにデータベースを組み込む?
>>383 は読んだがそれでも変な感じがする。

386 :デフォルトの名無しさん:03/05/13 03:12
DBというと頻繁に更新されるものという固定観念があるけど、
めったに更新されないものだったらハードに組み込んだほうが
効率的ってことでしょ。

387 :デフォルトの名無しさん:03/05/13 20:22
>>384
ハードに組み込むってのは 即値として入れるって意味かい?
ハードウエアって意味じゃないよね?

388 :山崎渉:03/05/28 13:03
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

389 :デフォルトの名無しさん:03/06/05 15:18
プログラミング初心者じゃない奴でもこんな事きくのか…

390 :デフォルトの名無しさん:03/06/05 15:36
ハードコーディング?

391 :デフォルトの名無しさん:03/06/05 16:46
あらかじめテーブルにdegreeごとに128倍したsin/cos値を格納して高速化とかやったっけ・・・

392 :デフォルトの名無しさん:03/06/21 08:39
FFTするのにかい? それは当たり前の手法で、テスト以外でそれをしないと普通笑われる。
だいたい、その種のテクニックをハードに組み込むって言い方はしないよ。

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


393 :デフォルトの名無しさん:03/06/21 08:41
ちなみに、ゲームとかで使うなら 度単位じゃなく、 256*x/2π にするけどな


394 :デフォルトの名無しさん:03/06/29 23:38
VB.NETもBeginUpdateでいいね。

395 :山崎 渉:03/07/15 10:25

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

396 :山崎 渉:03/07/15 14:18

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

397 :デフォルトの名無しさん:03/07/15 21:36
>>374
会社が使えというからさ

398 :山崎 渉:03/08/02 02:44
(^^)

399 :デフォルトの名無しさん:03/08/05 13:04
試みは面白い。あげ。

400 :デフォルトの名無しさん:03/08/05 14:00
VB使ってる時点で負けているのでsage

401 :デフォルトの名無しさん:03/08/13 02:00
言語は手段にしか過ぎないと思うが、VBを使って負けという意味がわからん。
そういうやつがどんなアプリ作っているか知りたい。

402 :デフォルトの名無しさん:03/08/13 15:02
>>401
相手にするなよ。VBすら使いこなせないヤツを。

403 :山崎 渉:03/08/15 16:00
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

404 :デフォルトの名無しさん:03/08/16 19:27
その手段がVBしか無い=負け
使い分けてるヤツは別だけどな

405 :デフォルトの名無しさん:03/08/16 22:31
ヽ(^^ ) ヨシヨシ

406 :デフォルトの名無しさん:03/08/16 22:35
VBしか使えないやつに限って使い分けろとか言うワナ。

407 :デフォルトの名無しさん:03/08/16 23:11
>>1
そこまで無理してVB使わなきゃいけないなら素直に
他の言語使った方がええんとちゃう?

408 :デフォルトの名無しさん:03/08/19 14:05
>・Variant型は使用せずに適切な型を使用する。
コンテナ使う以外にヴァリアントなんてつかうのか?

409 :デフォルトの名無しさん:03/08/19 16:24
>>408
データベースでは各データ型にNULLを代入することが出来る。

410 :デフォルトの名無しさん:03/08/19 17:59
VB糞すぎ

411 :デフォルトの名無しさん:03/08/19 21:27
アンチ 馬鹿だね

95 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)