- PR -

VB.VETで、処理速度を早くしたいのですが

«前のページへ 1|2|3|4|5|6|7|8|9 次のページへ»
投稿者投稿内容
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2004-02-18 10:41
【サブスレッド】iStationさん指定のC/C++作成のDllを使うと早くなる理由
引用:

はにまるさんの書き込み (2004-02-18 10:18) より:

　興味心からの質問です！
　なぜ、C/C++ で作成したdll を利用すると早くなるのですか？
　これは、ＶＢ言語よりＣ言語の方が早いと言う昔からの定説の一例でしょうか？

　御教授をお願い致します


　別件についは、下記の通りと認識しています。

　１．ADOオブジェクト と Excelオブジェクトを直接利用しない理由

　　オブジェクトが関数＋変数のメモリ領域を必要するのに対し
　　一旦、変数に格納して利用すれば変数だけのメモリ処理になる為。

　　また、Excelオブジェクトはデカイ



マネージドコード(VB.NET,C#.NET,C++.NET(マネージド))よりアンマネージドコード(C++(Win32))が早い理由は、ネイティブかそうでないかの違いです。

ちなみに、別件の１は違います。

変数にアクセスするのは直接だが、
ADOオブジェクト と Excelオブジェクトにアクセスするのは間接だ。

ってことです。

例をあげると、

変数にアクセスするのは、開発会社とエンドユーザが直接仕事するようなもの。
Excelオブジェクトにアクセスするのは、開発会社とエンドユーザの間に２次受け、３次受けがいるようなもの。

です。

ああ、もともとの質問も上の例で説明できるなぁ。
変数をC++(Win32)に置き換えて、
Excelオブジェクトをマネージコードに置き換えてもらえるといいと思います。

#ちなみに、例に他意はありません。
よねＫＥＮ
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2004-02-18 10:46
引用:

なちゃさんの書き込み (2004-02-17 20:26) より:
本題と直接関係ないところで引っ張ってすみません。m(_ _)m
引用:

kaguraさんの書き込み (2004-02-17 20:09) より:
for each i in a
i = 10
next
の方が速かったと。

このプログラムはバグっているように見えたりするのは気のせいですか？


バグってるとおっしゃっている理由が、
「配列aが値型の配列だから、このコードは無効では？」という意味なら
その通りだと思います。

--追記ここから---
　値型に限らず、参照型の場合でも列挙された各値を表す変数(この場合i)に
別のオブジェクト参照を代入するのは無意味ですね。
　プロパティやメソッドを介して何かしないと。
--追記ここまで---

下記で試せますが、Integerなどは値型のため、
a(x)の形で直接値を変更しなければ、a(x)の値は変更されません。
※xは添え字とします。

' (ソースコード)
Dim a() As Integer = {1, 2, 3}
For Each i As Integer In a ' (注)For文でのi As Integerは.NET Framework1.1からの構文です
' 変数iにはa(x)の値のコピーがセットされる。
' 変数iはa(x)とは無関係のためiに10を設定してもa(x)には影響しない
i = 10
Next

Debug.WriteLine(a(0))
Debug.WriteLine(a(1))
Debug.WriteLine(a(2))

' (結果)
' 1
' 2
' 3


[ メッセージ編集済み 編集者: よねＫＥＮ 編集日時 2004-02-18 11:03 ]
りばぁ
大ベテラン
会議室デビュー日: 2003/11/26
投稿数: 130
お住まい・勤務地: 愛知県
投稿日時: 2004-02-18 10:48
【サブスレッド】iStationさん指定のC/C++作成のDllを使うと早くなる理由
引用:

NAL-6295さんの書き込み (2004-02-18 10:41) より:

マネージドコード(VB.NET,C#.NET,C++.NET(マネージド))よりアンマネージドコード(C++(Win32))が早い理由は、ネイティブかそうでないかの違いです。



VBのEXEは、EXEといっても確か中間コードのようなものですよね？
VBランタイムがネイティブコードに変換して実行する形だった気がします。
※ウソだったらすみません＾＾；

で、次期ウィンドウズのLonghornではWinFXとかいうのが実装されるようですが、
従来のWin32APIを使用するより、WinFXを利用した方が速いそうです。
現状とはイメージ的には逆になってしまいますね＾＾；


[ メッセージ編集済み 編集者: りばぁ 編集日時 2004-02-18 10:49 ]

[ メッセージ編集済み 編集者: りばぁ 編集日時 2004-02-18 10:51 ]
よねＫＥＮ
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2004-02-18 10:56
引用:

りばぁさんの書き込み (2004-02-18 10:48) より:
VBのEXEは、EXEといっても確か中間コードのようなものですよね？
VBランタイムがネイティブコードに変換して実行する形だった気がします。
※ウソだったらすみません＾＾；


VB4までは中間コード(P-CODE)でしたが、VB5、6では、
コンパイル時に中間コードとしてコンパイルするか、
ネイティブコードにコンパイルするかを選べるようになっています。

・中間コードの場合、ランタイムありきで、
ランタイムで中間コードが解釈され実行されます。

・ネイティブコードの場合、まずランタイムが起動し、
その後、ネイティブコードに処理を移します。その中でVBの関数を使っている場合、
ネイティブコードからランタイムの関数が呼ばれます。

というような感じのはずです。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2004-02-18 11:37
引用:

よねＫＥＮさんの書き込み (2004-02-18 10:46) より:
引用:

このプログラムはバグっているように見えたりするのは気のせいですか？


バグってるとおっしゃっている理由が、
「配列aが値型の配列だから、このコードは無効では？」という意味なら
その通りだと思います。

--追記ここから---
　値型に限らず、参照型の場合でも列挙された各値を表す変数(この場合i)に
別のオブジェクト参照を代入するのは無意味ですね。
　プロパティやメソッドを介して何かしないと。
--追記ここまで---

追記されているように、何も行われないからです。
これは想定されていた動作ではないはずです。
ということでした。

--編集 引用失敗修正

[ メッセージ編集済み 編集者: なちゃ 編集日時 2004-02-18 11:52 ]
ｉＳｔａｔｉｏｎ
大ベテラン
会議室デビュー日: 2003/12/08
投稿数: 158
投稿日時: 2004-02-18 11:51
引用:

【サブスレッド】iStationさん指定のC/C++作成のDllを使うと早くなる理由

私の経験では、VB4.0の時代にVBの容易なUI開発環境からCで書かれた行列関連
の科学計算ライブラリを利用したいという理由でこの方法を取ったのですが、
えらく速度が向上した印象でした。たぶん、コンパイラの最適化のレベルの
違いから来るものと思います。将来は、CLRの最適化のレベルが向上すると
思いますので、時々比較をしたいと思っています。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-02-18 11:54
【サブスレッド】iStationさん指定のC/C++作成のDllを使うと早くなる理由

　NAL-6295 さんへ

　　ご返答とご指摘ありがとうございます。
　　.Net 言語の内部処理は全言語、一緒になると勘違いしていました。
　　勉強になります。

　皆様へ

　　追加質問です。調査し切れなかったのですが、
　　VB.Netの実行モジュールは、「マネージド」コードがデフォルトと
　　記述されていました。
　　初心者の考えですが、VBのコンパイルを「アンマネージド」指定で行い
　　ネイティブコードに変換すれば、DLL対策と一緒の利点を得れると考えました。

　　やはり、「アンマネージド」にすると注意点（制御する事）が増える為、
　　今回の様に一部（ＤＬＬ）を「アンマネージド」にして外出しにし、
　　元の処理（VB .Net）は「マネージド」がベストなのでしょうか？

　　# 話が深くなりそうならば、別スレッドにします。
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2004-02-18 11:58
引用:

はにまるさんの書き込み (2004-02-18 11:54) より:
【サブスレッド】iStationさん指定のC/C++作成のDllを使うと早くなる理由

　NAL-6295 さんへ

　　ご返答とご指摘ありがとうございます。
　　.Net 言語の内部処理は全言語、一緒になると勘違いしていました。
　　勉強になります。

　皆様へ

　　追加質問です。調査し切れなかったのですが、
　　VB.Netの実行モジュールは、「マネージド」コードがデフォルトと
　　記述されていました。
　　初心者の考えですが、VBのコンパイルを「アンマネージド」指定で行い
　　ネイティブコードに変換すれば、DLL対策と一緒の利点を得れると考えました。

　　やはり、「アンマネージド」にすると注意点（制御する事）が増える為、
　　今回の様に一部（ＤＬＬ）を「アンマネージド」にして外出しにし、
　　元の処理（VB .Net）は「マネージド」がベストなのでしょうか？

　　# 話が深くなりそうならば、別スレッドにします。



NAL-6295です。

ん？
そもそも、.NET開発環境でアンマネージドな、つまりWin32な開発ができるのは、
C++だけです。

VB.NETもC#.NETもコンパイル後はMSILが生成されるだけです。
«前のページへ 1|2|3|4|5|6|7|8|9 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）