効率的なソフトウェア開発で道を見失ってしまったのか？
(medium.com/@rufatmammadli)- 約 30MB の Word 文書をブラウザで編集しようとして入力遅延を経験し、最新のWebアプリの性能コストを実感する事例となった
- 文書はほとんどがテキストで、一部の画像と表だけを含んでいたが、Google Docs または Chrome 環境ではスムーズに処理されなかった
- 有料の Microsoft Office の代わりにインストールした LibreOffice では同じ文書がはるかに高速に動作し、Webアプリとネイティブアプリの違いが際立った
- 最新のWebアプリケーションがより多くのメモリとCPUを要求するようになり、ハードウェアの高スペック化が リソース集約型Webアプリ と結び付いているのではないかという問題意識につながった
- PWAやブラウザベースUIが広がる中でも、実際の使いやすさには ネイティブレンダリング と効率的なソフトウェア設計が依然として重要である
30MB文書で浮き彫りになったWebアプリの性能問題
- Googleアカウントとクラウド自動同期を活用できるため、まず Google Docs が選ばれた
- 文書をGoogle Docsにアップロードして入力してみると、文字が画面に表示されるまで数秒かかった
- ファイルサイズは約 30MB で、一部の画像と簡単な表があったものの、ほとんどはテキストだった
- ChromeまたはGoogle Docsがこの文書を適切に処理できなかったと判断した
- Microsoft Officeは有料のため除外され、代わりにインストールした LibreOffice では同じ文書が非常に高速に動作した
効率性をめぐるより大きな問い
- 最新のツール・フレームワーク・言語が、性能面でソフトウェアをより重くしているのではないかと考えさせられる
- リソース集約型のWebアプリケーションに対応するためにハードウェア仕様が高くなっており、純粋なネイティブアプリだけであればこうした要求は減っていた可能性があると見る
- モバイル機器に 16GB RAM が必要になる状況を例に挙げ、ソフトウェアのリソース使用量の増加を問題視している
- Webが単なるUIレンダリングエンジンのラッパーにとどまるのではなく、ネイティブレンダリング レベルの効率性を備えるべきだと見る
- 1966年のApolloコンピュータは 2KB RAM で月面着陸を可能にしたが、2024年のブラウザでは約30MBの文書作業すら難しいという対比が、最適化の必要性を強調している
1件のコメント
Hacker Newsでの意見
ネイティブアプリを作りたくても、AppleとMicrosoftにずっと阻まれているように感じる。開発者アカウント、バイナリ署名証明書、特に理由のない売上30%の手数料まで受け入れなければならず、とりわけMicrosoft側のAPIは混乱するほど変わってしまった
だから、より単純で安価なWebを選ぶことになる
署名されていないアプリもWindowsとmacOSで実行はできるが、警告が多く表示される。30%の手数料もMac App StoreやMicrosoft Storeを使う場合だけに該当し、Microsoft Storeはゲームでなく独自決済を使うなら手数料を取らないように見える
Appleはよく知らないが、Macアプリは開発者アカウントなしでも作れる可能性が高く、iPhoneには開発者アカウントが必要。以前見た価格は年**$99**で、アプリを本気で作るつもりなら大金ではない
チャージバックや返金処理にも費用がかかり、カスタマーサポートに時間を使うか人を雇う必要がある。年間売上が100万ドル未満ならAppleの手数料は15%なので、低価格アプリや付加価値のあるアプリなら、決済を自前で処理するよりAppleの方が良い取引かもしれない
この記事が、265語の記事1本に10.88MBをダウンロードさせるMediumに載っているのは皮肉だ
about:processで見ると、読み込みが終わって10分後でもこの記事がメモリ239MBとCPU 0.06〜0.2%を使っており、CPU時間の45%はGoogle reCAPTCHAで使われているようだったMozillaやGoogleのようなところが、ドメイン別のCPU・メモリ・エネルギー使用統計を集めて、性能を気にしない開発者たちを公に恥じ入らせてほしい
Webはまた2005年のように感じる。ただし今回はポップアップがページの中に埋め込まれている
gemini://gemi.dev/bin/waffle.cgiを開き、URLを貼り付ける。Geminiネットワークを使わない人は、URLのmedium.comをscribe.ripに変えればいい道に迷ったのは確かで、理由は簡単。そうできたからだ。抵抗が最も少ない道であり、だからその道を選んだ
ソフトウェアは数十年にわたりハードウェアの進歩にただ乗りしてきた。特にWebとデスクトップアプリでそうだった。ムーアの法則は祝福であり呪いでもあり、今日使っているソフトウェアは、そのただ乗りが真っ盛りの時期に技術を身につけた人たちが作ったものだ
今では8GB未満のコンピュータは使い物にならず、8GBでもかろうじて使える程度。新しいソフトウェアはElectronを使い、最低でも1GBのRAMを食い、ブラウザを含めてあらゆるものがばかげた量のメモリを使う
Windowsはさらに理解できない。母のコンピュータを手伝うたび、最近のi5と8GB RAMのPCなのに遅すぎて、起動やプログラムの実行、更新に時間がかかる。1分以上起動にかかるコンピュータなら窓の外に投げ捨てたくなるほどだ
複数の言語・環境のアプリケーション配布を解決したのではなく、コンテナエンジンで回避しただけ。ユーザーが望めばコンパイラやツールをインストールするビルドスクリプトも渡せるが、きちんとテストするのが難しいので結局コンテナを使う
RedbeanとCosmopolitan libcがこの問題を「解決」することに最も近いように見えた。ユーザーがアプリを簡単かつ安定して配布したいなら、コンテナには競争上の優位があり、そうするとすぐにディスク100MB以上とコンテナエンジンが付いてくる
国家や企業間の競争を技術開発の中核原理に据える限り、気候変動、生態系破壊、殺傷AIのような地球規模の危機を制御するのは難しい。最高レベルの組織原理として協業と協力が必要であり、競争は地球全体に巨大な負の外部性を生む
Lazarus、つまりFree Pascalで書かれたプログラムは、Windows 11のような最新のWindowsでも非常に高速に動く。デスクトップで特定の目的に合わせて書かれたソフトウェアを維持することが、速度と安定性には最も良い
ソフトウェアのあらゆる近代化は、ハードウェアとフレームワークの双方を含め、既存機能全体に課される税金のように作用する
複雑さが完全に間違った場所に積み上がってしまった
こうした不満は繰り返されるが、実のところ誰も本気では望んでいない状態でもある。
開発者は、完全に統合され接続された汎用コンピューティングプラットフォームであるWebを好み、ユーザーは十分に問題なければ性能をあまり気にしないように見える。結局、ソフトウェアはユーザーを過度に苛立たせない程度までなら悪くなっても許容される。
経営陣も、十分に良いソフトウェアがすでに開発されているなら、より良いソフトウェアを作ることには関心がない。誰かが急激な離脱が必要だと判断しない限り何も変わらず、どの観点から見ても変化へのインセンティブはほとんどない。
電波の弱い携帯回線で大きなアプリをダウンロードしたり、インターネットが不安定な地域に住んでいたり、低所得層・発展途上国で古い端末を使っていたりする人たちは、大きくて遅いアプリに不満を感じている。性能やアプリサイズを気にしていないように感じるなら、間違った相手に間違った質問をしているのかもしれない。
時間が経つと、不満を言う人だけが変わり者になり、それ以外の人はアップグレードするか、肥大化を受け入れるか、古いソフトウェアを使い続ける。
ただし、その肥大化がもたらす利点も見る必要がある。Google DocsがWordの複製にすぎなかったならそれほど使われなかっただろうが、無料で、複数の端末からアクセスでき、円滑に共同編集できるから使う人がいる。
また、肥大化に見えるものの一部は、実際には利便性の向上でもある。どんなサイズでも美しく見えるプロポーショナルフォント、Unicodeフォント、メモリより大きな文書の処理、作業中の文書と資料の切り替え、メモリ保護といった機能はリソースを多く使うが、生活の質を高めている。
現代のクラウドベース、あるいは半分オンラインの世界はユーザー視点ではかなり不自然で、収益化の必要がないOpenOfficeのような場合は、デスクトップアプリケーションのままでいられる。
誰もそれに不満を言わず、アプリの一部の性能がひどくても顧客からの苦情はまれだった。読み込みが60秒ほどになってようやく不満が出始める。
それでもそのソフトウェアは、1週間かかっていた作業を数分に短縮する非常に価値ある問題を解決していたため、顧客は絶賛していた。競争が激しくなるにつれて改善は必要になったが、ほとんどの人は本当に気にしておらず、常に優先順位の最下位だった。
タスクマネージャーを開くと、現在のデータベースがかなりの部分読み込まれているにもかかわらず、RAM 20〜30MBしか使っていないのを見るのは面白い。VLCとBlenderも似た例だ。
大半の人が開発者のせいにしているのは興味深いが、現実的にはすべてビジネス上の判断だ。
クラウドへ移行するのは、企業がサブスクリプションの安定収益を好むからであり、企業顧客はITチームを雇わなくてもよく、責任が外部に移るため高い稼働率を要求できる。性能はエンドユーザーにとって「十分に許容できる程度」であればよい。
オンプレミスソフトウェアのアップグレードを拒む顧客は、長い保守サイクルと終わりのないパッチを生み、Webで一度開発する方式は、プラットフォームごとに別々の開発者とテスターを置くより事業上有利だ。開発者の専門性だけでは、この根本的な力を変えることはできない。
派手な最新機能は使えないだろうが、Win7マシン上のCS4は追加費用なしで今も使える。
問題は、開発者がユーザーには買えない性能のマシンで開発し、性能や効率的なコードに注意を払わないことにある。
90年代初頭の MS Word はフロッピー数枚に収まり、メイン実行ファイルは 2MB だったと記憶している。RAM 全体が 2MB の 16MHz 386 でも問題なく動いた。
今やっていることの大半は当時もできていて、なかったのは文法チェッカーくらいだった。今では GB 単位で数え、1000倍大きくなったのに、何を得たのか分からない。道に迷っただけでなく、目的地も分からなくなってしまった
たとえば Linux の
dict.wordsだけでも 4.8MB あり、Arial Unicode は 20MB ほどあるフォントだ。作業中のアプリのアイコン1つが 400KB で、クラッシュ処理用の Google Crashpad ハンドラーも数 MB ある。4K トゥルーカラー画面は、640x480 16色画面より138倍大きい
あの頃の PC は UEFI なしでも起動でき、きちんと設定すれば Windows 3.11 もほぼ即座に立ち上がり、Word もすぐ開いた。
今の Word には非常に小さな機能やいくつかの大きな機能がそれなりに追加されているが、Microsoft がその気になればメモリ使用量を10分の1に減らせると確信している。ただしインセンティブがない。コンピュータは速く、メモリは多く、フロッピーに依存していないので、コストが余計にかかるだけだ。
ソフトウェアの肥大化は環境に無視できない影響を及ぼす可能性もあると思うが、十分に強い不満や、EU の反ソフトウェア肥大化法のようなものが出てこない限り変わらないだろう。
最近 GitHub で MS Word for Windows 1.0 のソースも見た。もともとの公開先は Computer History Museum で、https://computerhistory.org/blog/microsoft-word-for-windows-... から見られる。純粋な C で、大きな部分はアセンブリだったが、コードは現在の C/C++ の標準やパターン、言語機能とは比べものにならないほど汚かった
ソフトウェアは気体のようなもので、与えられた空間を満たすように膨張する、という表現を見たことがある。
ライブディストリビューションでも似たことが起きている。昔は CD-R に合わせるため 700MB だったが、今では 2GB USB に収まるものを見つけるのが難しくなった。それでも「minimal」が勢いを得ているのはうれしい
Nvidia はいったい何をダウンロードさせているのかと思う。絶対に使わない生成コードの組み合わせを何千個も落としているのだろうか
ただし、追加された肥大化した機能の間から欲しいものを探すのに、より時間がかかる
ミニマルなソフトウェアは存在するが、人々はあまりそれを選ばない。依存関係を保守的に選ぶのにかなり時間を使うと、軽量で性能の良いスタックにつながる。
最近は Lua、SQLite、Fennel[0]、Althttpd[1]、Fossil[2]、Mako Server[3] のようなツールを好んでいる。優秀で軽量、安定していて効率的なソフトウェアを無料で使えるが、よくある道から少し外れる必要がある。Stack Overflow で頻繁に聞くようなものではない。
フロントエンドについては少し葛藤がある。ネイティブアプリと Web ページを好む一方で Tiddlywiki を毎日使っており、Web アプリにも居場所はあると思っている。ただ、6MB の Tiddlywiki ファイルのタブが RAM を 155MB 使い、大きくカスタマイズした Emacs セッションは 88MB しか使わないので、筆者の問題意識には同意する。
[0]: https://fennel-lang.org/
[1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
[2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
[3]: https://makoserver.net/
もちろん誤った使い方もできるが、他の多くの言語と比べて Lua プログラムがどれほど小さく効率的になり得るかは、ほとんど衝撃的だ
問題はだいたいこんな具合だと思う。会社の役員が競争力のために開発者には最高級ハードウェアが必要だと判断し、開発者は会社から支給された 128GB RAM の高性能ノートPCで Web アプリを作る。
そして父親が使っている2010年製の家庭用 PC のような環境ではテストしないか、多くの部分が壊れて使い物にならないことに気づくほど頻繁かつ徹底的にはテストしない
そうすれば、モバイルファーストのレスポンシブ対応、限られた画面スペース、悪い接続での潜在的な問題を第一級の関心事として扱うようになる。
たいていはプロダクト責任者に問題を知らせても、そのまま流されてしまう。だから3つ目の項目は「2010年製の家庭用 PC でもテストしているが、より重要なステークホルダーにとっては関心事ではない」に直せる
最近、古いページを純粋な HTML とバックエンド生成方式から React に移行したところ、項目が千個ほどあるドロップダウンを開くのに数秒かかった。以前はページ全体が 100ms 程度で開いていた
最初は、最初の100件だけを表示し、ユーザーが3文字入力してからレンダリングしようという提案が出た。最近の現実はたしかにそうではある
もちろん実際には、ひどい React コードを修正して即座にレンダリングされるようにした
新しいフレームワークによって問題があまりにもはっきり見えるようになり、誰かが実際に直すための理由を作れるなら、むしろそのフレームワークを使う理由が増える
“idiomatic Ruby” や “早すぎる最適化は諸悪の根源” のような文章を掲げて、「性能より開発時間が重要だ」と言うからこうなった
昔は、より短い時間でより良いコードを書く開発者たちがいた
昔のコードには、今なら作られないようなひどいコードもたくさん見てきた