他の人のブレーキを回る

私は、Skypeからのメッセージ履歴を自己記述ユーティリティでバックアップしましたが、1年前は正常に機能しましたが、今では非常に遅くなっています。 これは受け入れられないかもしれません。 エクスポート速度のために、それは書かれていたので、私はプロファイラーに登りました。 その結果、彼はすべてを学び、複数の啓発を受けました。 ロードされたシステムDLLの関数に、名前だけでなく、名前だけでなくサブエンベロープを使用してブレークポイントを設定する必要があることがわかりましたが、それは簡単です。 Skype APIはひどく曲がった場所で書かれていることがわかり、それがブレーキをかける理由です。 外国のバイナリは時々非常に簡単に突き出して最適化できることが判明しています（MS Researchの栄光！）。 プロファイラーは軽く横たわるだけでなく、うそをつくことがあります。 せっかちな人向けのキーワード：C ++、VS、CodeAnalyst、Skype COM API、MS Research、Detours、SQLite。 そして、他の皆のために、詳細はカットの下にあります。



要するに、背景。 約1年半前、私は個人的に便利なテキスト形式でSkypeログをエクスポートしたかった（チャットからほとんど切り取り/貼り付け、わずかに改善された）。 エクスポート用に見つかったすべてのユーティリティは何にも適合しませんでした。 または、ログに300件弱の連絡先と360,000件を超えるメッセージがあるため、彼らは残酷にブレーキをかけました。 不快な形式でログを書きました。 これらすべてのトラブルを一度に。 愚かにも機能しなかった、など 私は自分で書くことにしました。 最初にPython用のSkype APIバインディングを試しましたが、遅いことがわかりました。 それから、Skype4COMとC ++を試してみたところ、かなり速くなりました。 結果は、ログをエクスポートするための非常に迅速なユーティリティです。 もちろん、ハードコア、コンソール、C ++。



数週間前にバックアップのことを思い出し、実証済みのユーティリティを起動しました...そして、私は終わりを待つことができないことに気付きました。 数分かかっていたエクスポートは、約30分で約10％進み、合計で約5時間のETAになりました。 許容できないほど長い。 元気？



ユーティリティをわずかに修正し、エクスポートされるチャットの数を制限します（私が理解しているように、Skypeは何らかの理由で同じ連絡先との個別の通信セッションを個別のいわゆるチャット、IChatに分割します）、基本時間に注意します。 次に、プロファイラーを起動します。幸いなことに、CodeAnalystはVisual Studioに統合され、わずか2〜3回のクリックで起動します。 そして、結果を注意深く見てください。



exporting chat 100/7014...

exported 3925 events in 18.1 sec











プロファイルは巻き毛のように見え、プロセス時間の81％がkernelbase.dllで消費され、さらに12％がskype4com.dllで消費され、プログラム自体を見ることもできません。 浮気！ スローダウンするのは（編集しやすい）私のコードではなく、何らかのサードパーティのコードです。 しかし、どれですか？



関数InternalLcidToName、LCMapStringEx、NlsValidateLocaleを自信を持って獲得してください。 これらの人々は誰ですか？ 私のコードからこのようなものを呼び出すことはありません。 だから私は電話していません。 だから、あなたはそれらがどこから呼び出されたかを知る必要があり、それからおそらくそれが明らかになり、それについて何ができるかが明らかになるだろう。 最上位関数InternalLcidToNameにブレークポイントを配置する必要があります。スタックを参照してください。 おっと、問題。 愚かには、ブレーカーの機能の名前が入れられません。 になる方法



私は2つの選択肢を知っていますが、おそらくもっと多くの選択肢があります。 最初に、プロファイル内の関数全体がトップエンドであるため、誤って実行を数回中断するだけなので、間違いなくそれに入ります。 第二に、わずかにググリングすることで、マジックライン{,, KernelBase.dll} @ InternalLcidToName @ 8を見つけることができます-犬と数字を使用して、目的の文字がそのように呼び出されることがわかります。 少し先に進むと、数値は常に4の倍数になり、一般的にスタックのサイズに非常に似ています。アンダースコアは、「パブリック」キャラクターの典型的な先頭の犬ではありません。 これに気付いたので、マングリングの正確なルールは、いくつかのオプション（犬/アンダースコア、4/8/12/16 ...）を整理するよりも、検索、研究、および適用するのにはるかに長く、16秒で_GetStringTypeWに入ることさえあります最初のショット。 さて、それほど遠くない未来から緊急のInternalLcidToNameに戻り、F5を繰り返して統計を収集すると、2つの興味深いことがわかります。 まず、ほとんどの呼び出しのスタックは次のようになります。



KernelBase.dll!@InternalLcidToName@8()

KernelBase.dll!_LCMapStringW@24() + 0x46 bytes

Skype4COM.dll!280c69f2()

// Skype4COM.dll

// ,







2番目に、繰り返し実行されるコードは次のようになります。 同時に、常に同じコードパスに沿って歩きます。



@InternalLcidToName@8:

752F6F33 mov edi,edi

752F6F35 push ebp

752F6F36 mov ebp,esp

752F6F38 push ecx

752F6F39 push edx

752F6F3A lea eax,[ebp-4]

752F6F3D push eax

752F6F3E mov dword ptr [ebp-4],ecx

752F6F41 call _NlsValidateLocale@8 (752F6E04h)

752F6F46 test eax,eax

752F6F48 je @InternalLcidToName@8+17h (7531BAB0h)

752F6F4E push eax

752F6F4F call _LocaleNameFromHash@4 (752F6F13h)

752F6F54 leave

752F6F55 ret







それら。 トッププロファイル機能の3つはすべて、_LCMapStringWになります。 内部の他の2つとは異なり、この関数はパブリックインターフェイスの一部であり、MSDNで説明されています。Googleは即座にmsdn.microsoft.com/en-us/library/dd318700%28v=vs.85%29.aspxのリンクを見つけます。何らかの理由で、あるロケールから別のロケールへの行のこの変換は、それ自体ではないにしても食べます。



さて、次のブレーク（シンボル_LCMapStringW @ 24がすぐにスタックに表示されるので便利です）をプログラムに追加し、さらに2つを見ます。 実際、API呼び出しは、この最も高価なLCMapStringの呼び出しにつながります（このため、プログラムが中断します）。 そして、どのパラメーターが最終的に転送されますか（関数自体へのこの内訳のため）。 関数を数回ステップスルーすると、コードは常にこのパスをたどることがわかります。



752F8188 push 0

752F818A push 0

752F818C push 0

752F818E push dword ptr [ebp+1Ch]

752F8191 push dword ptr [ebp+18h]

752F8194 push dword ptr [ebp+14h]

752F8197 push dword ptr [ebp+10h]

752F819A push dword ptr [ebp+0Ch]

752F819D push eax

752F819E call _LCMapStringEx@36 (752F81ACh)







したがって、すべてのパラメーターを非常に明確に見ることができます。 ここで、それらはすべてスタックにプッシュされます（逆の順序で）。 しかし、彼らの慎重な検査の結果は、最初は単に衝撃を与え、次に顎の不本意な落下と口からの泡の制御不能な漏出を引き起こします。



IChatMessage :: GetBodyメソッドの各（各）呼び出しで、次のことが発生することがわかりました。



最初に、LCMAP_LOWERCASEフラグ（「ロケールに基づいて小文字にする」）のみを持つデータ＃APPLICATIONCALLCHATMESSAGECHATMEMBERCHATGROUPSMSUSERVOICEMAIL＃がLCMapStringEx関数に到着しますが、ロケールはen-USです。 他のマシンには別のマシン（特にen-USのWindowsのインターフェイス言語があります）がありますが、通常のラテン文字を小文字に変換することは問題ではありません。 つまり、このデータは、長い行ではなく、いくつかの短い行でも到着しませんが、一度に1文字ずつ届きます。



その後、どうやら、この狂気を書いたヒンズー教徒は何かが間違っていると疑い始めます。別のプロトコルコマンドを小文字にする必要がある場合はどうでしょうか。ブレーキと多くのsiskollがありますか。 したがって、見事な予防的最適化。 そして、0から255までのテーブル全体が、再び呼び出しごとに1バイト、LCMapStringEx関数に到着します。 念のため、これはさらに2回続けて行われます。



その後、素晴らしい最適化が続けられます。 （または、コード内の別の場所で別のインド人によって行われた可能性があります。）繰り返しになりますが、0から255までのテーブル全体が関数に飛びます！ ただし、各バイトは3回連続して繰り返されます。 もちろん、このアプローチは以前のアプローチよりも正しいと私は考えています。 2つのクロノメーターは海では取得できません; 1つまたは3つを取得する必要があります。



合計で、1つのメッセージのテキストを取得しようとする[検閲済み]各試行に対して1000を超えるLCMapStringEx呼び出しが行われ、各呼び出しはサイズがちょうど1バイトの行で行われます。 これにより、5000テキストのメッセージテキストはCPUの5〜10秒かかります。 2年前のSkype COM APIのバージョンに依存せず、現在のSkype COM APIも同様にスローダウンします。



性交、Skype APIの内部性交。 強いプロを書くような気がします。



問題は明らかです、どうすればいいですか？ 理想的には、これらの呼び出しを完全に排除する必要がありますが、未知の数の場所でskype4com.dllにパッチを当てるのは怠zyであり（このLCMapStringが引き出されるさまざまなポイントの数を知っている）、そして2番目にそれはあふれています（誰が突然バグにつながるかを知っている）。 関数自体を置き換えて、1バイトの呼び出しの場合にすぐに終了するように頼みます。 単純な手法は長い間知られています：メモリ内の関数のアドレスを取得し、必要に応じて自分自身から関数にjmpを置き、必要に応じて最初に詰まった命令を実行し、jmp-threadを元の命令に戻します。 ただし、この手法は退屈で、アセンブラーペンで切るのは少し面倒です。



もはや必要ないことが判明しました！ MS Researchはすでに考え、すべてを行ってくれました。 自然界にはDetoursと呼ばれるライブラリがあり、それだけでそれ以外のすべてを実行できます。 たとえば、一部のサードパーティの.exeの関数をまったく変更せずに置き換え、DLLから実装をその場でプッシュできます。 まあ、私のユーティリティのために、Detoursは必要な置換のためのシンプルで直感的なC / C ++インターフェースを提供します。simple.cppという名前の例は十分です。 生活賃金（detours.h、syelog.lib、detoured.lib、detours.lib）にフックし、20行のコードを追加し、...



#define PROTO (LCID Locale, DWORD dwMapFlags, LPCWSTR lpSrcStr, int cchSrc, LPWSTR lpDestStr, int cchDest)

static int (WINAPI * TrueMap) PROTO = LCMapStringW;

int WINAPI MyMap PROTO

{

if (Locale==1033 && dwMapFlags==256 && cchSrc==1)

{

*lpDestStr++ = *lpSrcStr++;

*lpDestStr++ = 0;

return 1;

}

return TrueMap(Locale, dwMapFlags, lpSrcStr, cchSrc, lpDestStr, cchDest);

}



// ...

DetourRestoreAfterWith();

DetourTransactionBegin();

DetourUpdateThread(GetCurrentThread());

DetourAttach(&(PVOID&)TrueMap, MyMap);

LONG error = DetourTransactionCommit();

if (error != NO_ERROR)

printf ( "error detouring LCMapStringW(); export might be slower (code=%d)\n", error );



// ...



exporting chat 100/7014...

exported 3925 events in 5.8 sec







全体として、システムコールを使用して全員を小文字に変換する一般的で不要な（！）バイト単位の翻訳を短縮し、プログラムを全体で3.1倍高速化しました。 悪くない、悪くない。 プロファイルをさらに調べます！







絵は劇的に変化しました。 KernelBase.dllが消費するのはわずか20％で、残りはskype4com.dllの未知の荒野で実行されます。 ただし、GetDriveType呼び出しを使用して状況を確認することを明確に要求します。 この関数は、ディスクのタイプ（リムーバブル、非リムーバブル、CD-ROM、RAM、またはネットワーク）を判別し、何千回と呼ばれる場合、結果のキャッシュを要求します。 ここで、別の小さな発見を待っています。



プロファイラーが嘘をついており、かなり目立っていることがわかります。 関数_GetDriveTypeWは、プログラムの全期間にわたって1回呼び出されます。 プロファイルでは、100ではなく1000のチャットをエクスポートしても、かなり顕著に反映されますが、実際には時間を消費しません。



ただし、プロファイラーは_GetStringTypeWについて嘘をつきません。 _LCMapStringW呼び出し分析に似たいくつかの簡単な操作を行った後、エクスポート中に、その親関数GetStringTypeExも0から255までのすべてのバイトに対して常にプルされることがわかります（誰が疑うでしょう）。 GetStringTypeExをインターセプトし、さらに20行のキャッシュから1バイトのケースの結果を返すことにより、さらに15％の加速が得られますが、3.6倍しかありません。



exporting chat 100/7014...

exported 3925 events in 5.0 sec







興味深いことに、この最適化の後、KernelBase.dllはプロファイルから完全に消えます。 残りの時間の62％はskype4com.dllによって消費され、別の12％はntdll.dll（割り当てとクリティカルセクション用）を使用し、プログラム自体は約8％を消費し、その後、システム全体を消費します。 最適化の可能性は3〜5倍あると思われますが、MSDNの関数名とそれらのドキュメントで何が起こっているかをすぐに処理できます。また、内臓skype4com.dllを分解するホットスポットはありません。 そして、大切な360,000件のメッセージのエクスポートにはすでに10分もかかりません。これは許容範囲です。



短い技術的要約は、記事の冒頭ですでに要約されているようです。 周りには、Skypeなどの著名な企業を含む生きている人々がいます。また、ある場所では、生きている人々のようにコードを記述しています。 場合によっては、ソースが存在しないサードパーティのライブラリでは速度が低下しても、最小限の労力で状況を修正できます。 ブレーキを調べて最適化するのに、ほんの数時間しかかかりませんでした（迂回の習得を含む）（初めて見たときと試してみたとき）。 メモを準備するのにもっと時間がかかったのではないかと思います。 強力なツールは、正しく使用すると、明らかに小さな奇跡を起こすことができます。



...そして、Skypeは、通常のSQLiteデータベースにメッセージログを保存します。このデータベースは、通常のSQL構文を使用してSQLite Browserによって正常に開かれ、管理されます。 1つの連絡先の履歴を選択的に消去しますか？ お願いします。 すべての人にとって、適切な深さまで（設定を変更するとき、Skype自体は何をしませんか）？ 簡単です。 むき出しのベースを最適化しますか？ もう一度ワンクリック。 しかし、これは別のC ++ではありません-naya story;）



最適化を成功させます。