文字列置換に関する雑記

2002年10月01日（火）   CodeGuard 作った一括置換プログラムをデータのあるフォルダに入れて使いはじめたのですが、あれ？、.cglというファイルが出来ています。よく考えたらプロジェクトの設定でCodeGuardを有効にしたままにしていたのでした。    それをはずしたら、ProgressBar付き「置換バッチ」モードで今まで（プログラム内計測で）１５秒かかっていた処理が１秒で終わりました。体感だと３秒ぐらいですか。同じデータでfeditだと体感１０秒ぐらいなので、これなら十分です。    ちなみに、バッファの件もこれに関連しているのかと思い、設定を4Kから4Mに変えてみましたが、それだとプログラム内計測で３０秒かかりました。よってバッファを大きく取ると遅くなるのはCodeGuardと関係ないようです。    【今日の日経平均】　9,162 -221

2002年09月29日（日）   バッファ 置換の際の検索のアルゴリズムとしてＢＭ法などを検討してみたのですが、今回の場合、検索文字列が長くて１２バイトぐらいなので、ダブルバイトのハンドリングを考えるとパフォーマンス的にコストが高すぎます。そこであきらめてロジックをいろいろ変えてみたのですが、やはり数秒しか早くなりません。    あきらめてバッファの切れ目のテストでもしようと、Ｉ／Ｏバッファのサイズを小さくしてみると、おや、ロジックは同じなのにスピードが速くなります。最終的には「辞書引き」モードと３秒差まで差を縮めることができました。これならまあ使える程度です。    しかし、同じＩ／Ｏルーチンを使った「辞書引き」モードだとバッファの量を変えてもスピードは変化しないのに、なぜ「置換バッチ」モードだと早くなるのかよくわかりません。    まあ、いいや、ということで、Windows型のプログラムにしてプログレスバーを付けて一応出来上がりです。またInspironの機嫌が悪くなるといけないのでCD-Rにバックアップをとっておきました。

2002年09月28日（土）   何か 「置換バッチ」モードを切り替えで選択できるようにしたのですが、「辞書引き」モードの４倍ぐらい遅いです。同じデータでfeditは「辞書引き」モードと同じぐらいのスピードを出しているので、何かもっといいアルゴリスムがあると思うのですが。    本日の自転車の走行距離は最低必要限の6kmでした。

2002年09月25日（水）   一括置換 一括置換にfeditというプログラムを使ってみたのですが、出力1024バイトあたりで改行が入ってうまくいかないことがわかりました。やっぱり、このぐらいは自分で作れということでしょうか。    【今日の日経平均】　9,165 -156

2002年09月13日（金）   複数文字列一括置換 a,b  c,d  e,f    のような「元,先」という形式のTextファイルを用意しておけば、一気に変換してくれるようなソフトを探してみました。その中で    ・Techno104というサイトにある「fedit」  ・「ListConvert」という秀丸用マクロ    がよさそうかな、と思いました。feditの方はコマンドラインで「テーブルファイル」と「変換したいファイル」を指定するだけなので、シンプルでいい感じです。ListConvertの方は、どうせ変換テーブルの編集は秀丸の中で行うので手間がいりません。ただ実行時にテーブルファイルを開いていると動きがおかしくなるというマクロ特有の画面スイッチの問題があるので、その点は取り扱いに注意が必要かもしれません。    あと最終的にテーブルの中身を「元」の文字数で降順にソートしなければいけないので、久しぶりに秀丸のマクロを書くことになりそうです。    【今日の日経平均】　9,241 -173