アカウント名:
パスワード:
俺もiTextやApache PDFBoxでゴチャゴチャとpdfを扱った経験はいくつもあるけどExcelのマクロだって、使ってみりゃいい具合に強力なんよな。VBAはちょっと慣れないけど。セル結合もセルの幅も背景色も、ロジックで調整し放題だし。DBにも普通に繋げられるし。他のドキュメントも開けるし。
マクロは自分一人で管理する分にはいいと思うよ。VBA環境はいい所もある。
ExcelVBAの地獄なところは、・テキストがxlsmに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)・テストが書けない(工夫(ry・エラー行が特定できない事がある・謎のリソース不足で落ちる(VBAで不足するほどリソースを大量に使う発想がそもそもおかしいのだが)・TryCatchがない・動的配列が無い(正確にはそういったものは皆無ではないがReDimとかいつの時代のアレだ)・辞書(連想配列)が使い辛い・当然ラムダとかない、というか関数参照が碌に扱えないのでちょっと本腰入れてプログラム書こうとか
Excel内部にはマクロを持たせず、PowerShell等、外部からExcelを操作したらどうかと検討したこともあったけど利用する側の利便性も考慮したベストな方法が見つからない。
外部からだと、1変数参照に「ExcelOpen→参照→ExcelClose」とかなるからのろさダイナマイトになるでしょう。#外部からシートをなめるのと、検索条件をシートの空きに書いて#一気にVLookupするのとの時間差がそれ。
うーん、dde操作イメージかな?
普通は、COM操作になるので、参照毎にOpen,Closeする必要なんてないと思いますよ。
>参照毎にOpen,Closeする必要なんてない
たしかにOpen,Closeというのは言い過ぎだったかも知れませんが、内部からCells(,)を呼ぶのと、外部から呼ぶのでは速度が段違いです。
1000行位なめると、その差は歴然でした。Open,Closeはうそかも知れませんが、なんらかのオーバーヘッド(内部なら保持可能な参照を、外部からでは持ち切れず、一々、参照を取り直しとか)が有るのは事実です。
内部(COMインターフェースも不要)と外部(COM操作、Excel.Applicationへの参照を変数に入れ、それに対する操作)での比較です。それはご指摘の通りです。
それがなきゃWSH/HTA(JScript)+polyfillでそこそこ快適なんだけどねぇ……簡単なデータ読むだけなら全選択コピーからのクリップボード読みでまぁまぁ行ける。メタ文字対策するならCSVとかでファイルに吐かんと駄目だろうけど。書式とかも読むならどうしようもない。
遅くなる原因はExcel由来オブジェクトの実体が全部Excelプロセス内に居て、配列アクセス含めた全操作が全部リモートプロシージャコールかなんかになってるんじゃないかと。COM経由でマクロ叩いてデータ変換掛けてプリミティブでデータ貰えれば良いんだが、COMから楽に叩けるのはクソ古いExcel互換マクロでWin32API呼ぶ位しか用途の無いやつだったり。
マーシャルが遅いので1000回取ったら遅いrangeだったかで一気にどかっと取ればだいぶ速いよ
識者に教えていただきたいのですが、VBAでCells(,)とやるのと、外部のプログラムから相当の処理をやるのと速度に違いがでるのでしょうか?
VBAのプログラムはExcelファイルの中に組み込みという違いがありますが、技術的にはどっちもCOMで通信してるのであってそこの性能は変わらないとおもってます。
アウトプロセス(OLEサーバ)とインプロセスの差では無いでしょうか?
後者ならポインタを保持すれば参照になるでしょうけれど、前者は先方のプロセスのポインタは無意味です。意味のある様に一々、解釈しなおさないといけないのでしょう。そして、Excelはその再解釈がとくに重い(accdbなどと比べて)データ構造だからではないかと想像します。
それならxlsxをXMLデータとして直接扱った方が速いでしょ
すごい! 有難うございます。
Book1\xl\worksheets\sheet1.xmlを7zで解凍:
<?xml version="1.0" encoding="UTF-8" standalone="true"?><worksheet xr:uid="{C1B9B2EA-E173-4F57-A2EB-92CA6B3B9CD1}" xmlns:xr3=略 ><dimension ref="E20:F20"/>
<sheetViews>
<sheetView workbookViewId="0" tabSelected="1"><selection sqref="F21" activeCell="F21"/></sheetView></sheetViews><sheetFormatPr x14ac:dyDescent="0.4" defaultRowHeight="18.75"/>
<sheetData>
<row r="20" x14ac:dyDescent
そんな原始的な事しなくても、OpenXML(MS謹製)やEPPlus(サードパーティー)などを使えば簡単に参照、編集できますよ。
特に後者はデータ構造がExcleオブジェクトに似た構成になっているので直感的に触れますし。
別プロセスから触る場合は焼け石に水。どかっと取っても取った現物がExcel側にいるのか、それに対するアクセスが遅い。
あれ、そうでしたか記憶腐ってたかな…すんません
Rangeで取ってハッキリ早くなるのはExcel内で動くVBAとかじゃないかと。外部からでもまぁちょっとは早くなるけど・・・
COMアドインにしてしまうのが、簡単だと思いますよ。
配布もclickonceで簡単にできますし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
自分もそうするかもなあ (スコア:0)
俺もiTextやApache PDFBoxでゴチャゴチャとpdfを扱った経験はいくつもあるけど
Excelのマクロだって、使ってみりゃいい具合に強力なんよな。
VBAはちょっと慣れないけど。
セル結合もセルの幅も背景色も、ロジックで調整し放題だし。
DBにも普通に繋げられるし。他のドキュメントも開けるし。
Re: (スコア:0)
マクロは自分一人で管理する分にはいいと思うよ。VBA環境はいい所もある。
ExcelVBAの地獄なところは、
・テキストがxlsmに埋め込まれてソース管理できない(工夫すればできるが労力が無駄)
・テストが書けない(工夫(ry
・エラー行が特定できない事がある
・謎のリソース不足で落ちる(VBAで不足するほどリソースを大量に使う発想がそもそもおかしいのだが)
・TryCatchがない
・動的配列が無い(正確にはそういったものは皆無ではないがReDimとかいつの時代のアレだ)
・辞書(連想配列)が使い辛い
・当然ラムダとかない、というか関数参照が碌に扱えないのでちょっと本腰入れてプログラム書こうとか
Re:自分もそうするかもなあ (スコア:0)
Excel内部にはマクロを持たせず、PowerShell等、外部からExcelを操作したらどうかと検討したこともあったけど
利用する側の利便性も考慮したベストな方法が見つからない。
Re: (スコア:0)
外部からだと、1変数参照に「ExcelOpen→参照→ExcelClose」とかなるから
のろさダイナマイトになるでしょう。
#外部からシートをなめるのと、検索条件をシートの空きに書いて
#一気にVLookupするのとの時間差がそれ。
Re: (スコア:0)
うーん、dde操作イメージかな?
普通は、COM操作になるので、参照毎にOpen,Closeする必要なんてないと思いますよ。
Re: (スコア:0)
>参照毎にOpen,Closeする必要なんてない
たしかにOpen,Closeというのは言い過ぎだったかも知れませんが、
内部からCells(,)を呼ぶのと、外部から呼ぶのでは速度が段違いです。
1000行位なめると、その差は歴然でした。Open,Closeはうそかも知れませんが、
なんらかのオーバーヘッド(内部なら保持可能な参照を、外部からでは持ち切れず、
一々、参照を取り直しとか)が有るのは事実です。
内部(COMインターフェースも不要)と外部(COM操作、Excel.Applicationへの
参照を変数に入れ、それに対する操作)での比較です。
それはご指摘の通りです。
Re: (スコア:0)
それがなきゃWSH/HTA(JScript)+polyfillでそこそこ快適なんだけどねぇ……
簡単なデータ読むだけなら全選択コピーからのクリップボード読みでまぁまぁ行ける。
メタ文字対策するならCSVとかでファイルに吐かんと駄目だろうけど。
書式とかも読むならどうしようもない。
遅くなる原因はExcel由来オブジェクトの実体が全部Excelプロセス内に居て、
配列アクセス含めた全操作が全部リモートプロシージャコールかなんかになってるんじゃないかと。
COM経由でマクロ叩いてデータ変換掛けてプリミティブでデータ貰えれば良いんだが、
COMから楽に叩けるのはクソ古いExcel互換マクロでWin32API呼ぶ位しか用途の無いやつだったり。
Re: (スコア:0)
マーシャルが遅いので1000回取ったら遅い
rangeだったかで一気にどかっと取ればだいぶ速いよ
Re: (スコア:0)
識者に教えていただきたいのですが、VBAでCells(,)とやるのと、外部のプログラムから相当の処理をやるのと
速度に違いがでるのでしょうか?
VBAのプログラムはExcelファイルの中に組み込みという違いがありますが、技術的にはどっちもCOMで通信してるのであって
そこの性能は変わらないとおもってます。
Re: (スコア:0)
アウトプロセス(OLEサーバ)とインプロセスの差では無いでしょうか?
後者ならポインタを保持すれば参照になるでしょうけれど、前者は
先方のプロセスのポインタは無意味です。意味のある様に一々、解釈
しなおさないといけないのでしょう。そして、Excelはその再解釈が
とくに重い(accdbなどと比べて)データ構造だからではないかと
想像します。
Re: (スコア:0)
それならxlsxをXMLデータとして直接扱った方が速いでしょ
Re: (スコア:0)
すごい! 有難うございます。
Book1\xl\worksheets\sheet1.xmlを7zで解凍:
<?xml version="1.0" encoding="UTF-8" standalone="true"?>
<worksheet xr:uid="{C1B9B2EA-E173-4F57-A2EB-92CA6B3B9CD1}" xmlns:xr3=略 >
<dimension ref="E20:F20"/>
<sheetViews>
<sheetView workbookViewId="0" tabSelected="1">
<selection sqref="F21" activeCell="F21"/>
</sheetView>
</sheetViews>
<sheetFormatPr x14ac:dyDescent="0.4" defaultRowHeight="18.75"/>
<sheetData>
<row r="20" x14ac:dyDescent
Re: (スコア:0)
そんな原始的な事しなくても、OpenXML(MS謹製)やEPPlus(サードパーティー)などを使えば簡単に参照、編集できますよ。
特に後者はデータ構造がExcleオブジェクトに似た構成になっているので直感的に触れますし。
Re: (スコア:0)
別プロセスから触る場合は焼け石に水。
どかっと取っても取った現物がExcel側にいるのか、それに対するアクセスが遅い。
Re: (スコア:0)
あれ、そうでしたか
記憶腐ってたかな…すんません
Re: (スコア:0)
Rangeで取ってハッキリ早くなるのはExcel内で動くVBAとかじゃないかと。
外部からでもまぁちょっとは早くなるけど・・・
Re: (スコア:0)
COMアドインにしてしまうのが、簡単だと思いますよ。
配布もclickonceで簡単にできますし。