アプリ起動の高速化＠ubuntu

拙生のような貧乏人と違い、贅沢な環境も難なく構築できる
資金力をお持ちの方なのに、もったいないから＆安いから
という理由で二昔前のPCを集めてきて、ただだからという理由で
ubuntuを使っている御仁がいらっしゃいます。
金を残す人ってそうなんだろうなぁ。。。
なんて感心しているというお話じゃございませぬ。（w

実はこの御仁結構こだわるかたで、アプリの起動をもっと
早くしたいと色々頑張っておられます。
で、先日尋かれたのがprelinkを導入したみたけど、実行すると
not an ELF objectと怒れれっちゃうけどどぉして？というものでした。

あのぉ～、prelinkってELF（Executable and Linkable Format）の
オブジェクトに対して共有ライブラリから必要部分を事前に
スタンバイさせておいて、プログラムの起動を早くする機能だから、
ELF形式じゃないものは怒られるのが当たり前だと思うんですけどぉ。

さらに御仁が語るところによると、ならばと色々ググッってprelinkの
コンフィグファイルに思い当たるものをどんどん登録し、-aオプションを
つけてprelinkを実行したということです。
おぉぉ！なかなか賢いじゃん。
つまりコンフィグファイルに登録したものの中でprelink可能なものは
全てする、というのが-aオプションなんです。

で、拙生が御仁に尋ねたのは、マシーンスペックは？
返ってきたのはFMV-D3290の中古でCPUがCeleron1.8GHz、
メモリは２GB、HDDは８０GBで７5GB以上は使用していたはず
とのことでした。

ちょっと待ってぇ！！
prelinkを導入するならもっと仕組みを調べてからにしましょうぜ。
prelinkすればプログラムに使用しているバイナリが、プラスされた
ライブラリ分だけ増大しちゃうんですけど。
できるやつを全部prelinkしちゃったらHDDの容量は大丈夫かいな？
prelinkだけでなくELFについてももうちょっとお勉強が必要ですね。
といっても拙生自身もそんなに詳しいわけじゃありませぬが。。

【ELF概要＠拙生流】

（　＠拙生流とするときは、書いたことへの検証は参考文献や
　ググり詣でで行っていないため、あまり自信がないときに
　多用しますので要注意！です・・・笑　）
　

アプリを構成するライブラリには、アプリが違っても汎用的な機能で
共通して使いまわせるものが数多くあります。
アプリそれぞれにライブラリを持つこと（静的ライブラリ）は
プログラムの大きさや開発者の手間を増大させるので、共有するための
動的ライブラリを用意しておき、それを利用することで無駄を省こう
という考え方です。
ELF 共有オブジェクトは概ね標準共有ライブラリという意味です。

【ELFの功罪】

功　プログラム容量が小さくて済む。
　　開発者の手間が減る。

罪　起動が遅い

共有ライブラリを利用する方法は拙生の知る限り、動的リンクと
動的ロードの2通りですが、いずれにしろアプリを実行した
ユーザー空間の仮想メモリに必要なライブラリをロードして
再配置する分、静的ライブラリより起動が遅いのは仕方ありません。
prelinkすれば早くなる代わりに余分にリソースを喰うという
トレードオフ関係にあります。

ちなみに効果が体感できるほど飛躍的なものかどぉかは別として、
起動を並列処理させたりマウントをRAMドライブで駆動させたり
（UPSなどしっかりした電源環境が必要）キャッシュ関係をいじったり、
高速化に関する手法はたくさんあるのですが、下手をやらかすと
お釈迦にしてしまう可能性があり、prelinkなどよりはハードルが
ずっと高いものもあるので、事前のお勉強がとても大事になります。

さてさて、結論めいた話でまとめると
prelinkをするにはHDDを容量を大きなものにしましょうぜ。
内臓SSDにしたらさらに高速です。
データを外付けストレージやクラウドにして空きスペースを
確保したらその分遅くなっちゃうので、お勧めはもっと良い
パソコンにしろ！ってことですか。（結局はそこかい！？　w）
拙宅ubuntuメインマシーンはWindowsマシンのお下がりで
初期の世代といえどCPUはi7(2.93GHzx4core/8s)、メモリは８GB、
256GBのSSDですから、何も細工せずとも早さは超特急ですよ。
　　　　　　　　　　　　　　　　　　（笑笑笑＠勝ち誇った笑い

何て書いたら本気出されてi7-5960X （8core/16s　DDR4）
SSDx4ーRAID6のストライピングあたりで対抗されたら怖いので
程々にしておきましょ。＠実は煽り

＊PS

高速化の一つとして先日POSTしたCCACHEも有効な手段ですね。