Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part28
https://mevius.5ch.net/test/read.cgi/tech/1742805420/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/05/22(木) 15:32:41.47

これがAI時代のプルリクエストか
https://github.com/microsoft/edit/pull/164

**デフォルトの名無しさん** · 2025/05/22(木) 15:37:54.16

>>746
テストしてから出直してくれって優しい作者だな
Microsoftってもっとキツい印象あったさかい

**デフォルトの名無しさん** · 2025/05/22(木) 15:38:10.97

>>746
さっそくRustの今後
> これからは質が悪くなる一方だな、人的にも成果物的にも

**デフォルトの名無しさん** · 2025/05/22(木) 15:40:33.23

情報があればLLMの精度も上がらんかな

**デフォルトの名無しさん** · 2025/05/22(木) 15:42:18.46

>>746
メソッド乙

複おじ: 気になる、貼る、煽る、反応を見る、切る

**デフォルトの名無しさん** · 2025/05/22(木) 15:45:34.88

>>749
もっとLLVMへの指定とLLVM側での対応が増えれば解決する問題ではある
ケースによってrustcまたはRustソースコードで指定

**デフォルトの名無しさん** · 2025/05/22(木) 15:46:16.26

>>747-748の通り一瞬で分かるのに、>>746は本当に英語出来ないのか

>>746が
> これからは質が悪くなる一方だな、人的にも成果物的にも
を体現しているな

**デフォルトの名無しさん** · 2025/05/22(木) 15:48:23.67

>>751
じゃあ、gccrsでビルドしなおすだけで$20,000もらえるの？

**デフォルトの名無しさん** · 2025/05/22(木) 16:30:41.91

>>753
ただし欧米かニュージーランドかオーストラリア在住が必須とあるので、日本人お断り案件

**デフォルトの名無しさん** · 2025/05/22(木) 16:33:47.34

最適化ってのはレジスタ割り当てとかは合理的な割り当てアルゴリズムがあるが、
ヒューリスティックな手法も合わせて使ってる。
大量の置き換えパターンを辞書として持っておくという泥臭い仕組みだったりする。
これは言語の性質によるので言語中立で高性能な最適化機構を持ったコンパイラバックエンドなんて無理なんじゃねーかなと思ってる。

**デフォルトの名無しさん** · 2025/05/22(木) 17:31:19.79

Rustって泥臭い役割を避けているから愛され言語イエーイしてるよね

**デフォルトの名無しさん** · 2025/05/22(木) 17:33:10.42

Rustはルールが厳しくてすんなり書けない事が多い　お世辞にも書きやすい状況じゃない
それ自体は仕方がないけど回避するために何か方策が必要になることが多い

現在のstableでは機能不足でありeditの作者はnightlyビルドを使ってる
関数の充実が待たれるが結局その都度使える関数を探さないといけない

**デフォルトの名無しさん** · 2025/05/22(木) 17:42:54.78

ネット上での統合失調症【糖質】の機器の説明との押し問答と同じ状態を表している
無知だからこうなのだよ！
※ 周囲の人は統合失調症の思考を聞いているのでしょうならその思考通りに統合失調症は話せばよいのでしょう？
※同じ話を統合失調症も聞いておりますけれど？

「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に
2025年05月22日 14時00分
https://gigazine.net/news/20250522-github-copilot-coding-agent-error/
>>「AIが『直しました』と言い、人間が『いいえ、まだ壊れています』と言い、AIが変更を加えて『問題ありません、直りました』と言い、さらに数回繰り返すところが気に入っています」といったコメントや、
>>「残念なことに、私もまさにこのパターンに従う人間の開発者と一緒に働いたことがあります」とのコメントのほか、
>>「問題は、今後10年間でモデルが実際に改善され、実現可能になるという確かな証拠がないことです。テストと研究はともかく、製品に導入するのは全く別物です。大手ソフトウェア企業は、株主の利益を満足させるために運営されています」など、未完成で不確かな製品を公開することに異議を唱えるコメントが付けられました。

**デフォルトの名無しさん** · 2025/05/22(木) 17:45:59.66

生ごみ拾ってくんな

**デフォルトの名無しさん** · 2025/05/22(木) 18:00:14.35

>>755
>>500,736 の場合は特にasmコードが実行時間の大半を占めている前提で考えて
「inline」asmとその前後(のCコードのgcc出力)が相性良く仕上がっているからかなぁ、と思ったら
dav1dにはinline asmはなくて関数単位でasmを使っているだけの様に見える
https://code.videolan.org/videolan/dav1d

それでもgccとclangで差があると言うのだから「泥臭い」最適化には頭が上がらない

ましてやasmコードそのままに横入り/ただ乗りするプロジェクトに憤りを感じる

**デフォルトの名無しさん** · 2025/05/22(木) 19:00:56.60

考えて見たら
> 横入り/ただ乗りするプロジェクト
の方は内々ではちゃんとお金出すってさ、videolan側で変更が発生した場合
videolan側へも関わった人数分の懸賞金配分があるべきだよね

**デフォルトの名無しさん** · 2025/05/22(木) 19:18:13.29

>>760
オープンソースライセンスで、しかも二条項MITという緩いライセンスを選択している以上はただ乗り歓迎という意思表示だろう。
性能的に不十分ではあっても技術的開拓をしてる分だけ単なるユーザよりは貢献してるわけだし、そこに憤るのは筋違いだと思うぞ。

**デフォルトの名無しさん** · 2025/05/22(木) 19:23:31.51

>>762
tailwindも勘違いしてる

**デフォルトの名無しさん** · 2025/05/22(木) 20:47:22.62

ガーイガイガガイガガイガガイ私ガイガイガイガイゴミガイジ
周りに迷惑をかけ続けるクソガイジ
プログラミング出来ないイキリ無能
死んだ方がマシ人間
ガイガイクソガイジ

**デフォルトの名無しさん** · 2025/05/22(木) 20:47:47.49

死にますクソガイジです

**デフォルトの名無しさん** · 2025/05/22(木) 20:49:14.84

やる気ある無能クソガイジだけど質問ある？

**デフォルトの名無しさん** · 2025/05/22(木) 20:53:07.80

なんでRustで作られたモノが極端に少ないのかと思ってたけど
理由が分かっちゃったよ

**デフォルトの名無しさん** · 2025/05/22(木) 21:18:38.27

rav1d高速化コンテストだけど
MaybeUninit を使ってゼロクリアを避けただけで
実行時間差の2割が解決したらしい

**デフォルトの名無しさん** · 2025/05/22(木) 21:25:17.88

>>767
新たに作られたものはRustが多い

**デフォルトの名無しさん** · 2025/05/22(木) 21:28:24.04

>>767
Rust の公式リポジトリ (crayes.io) のクレートが 18 万個。
python のリポジトリ (pypi.org) にあるパッケージが 63 万個。
JavaScript が 200 万個。

まあ比較すれば少ないが、 JavaScript の1割弱ならかなり多い部類だろ……
Hakell だと1万7千、OCamlなんて4千ちょっとだぞ。

**デフォルトの名無しさん** · 2025/05/22(木) 21:31:44.54

>>768
そんな基礎的なことをやっていなかったことに驚いた
何かデータ構造ベクタとかスタックとかキューとか作ったことがあれば初期値のサイズ0で必ずMaybeUninit使うのにな

**デフォルトの名無しさん** · 2025/05/22(木) 21:33:15.61

>>770
こっちが恥ずかしくなる

**デフォルトの名無しさん** · 2025/05/22(木) 21:33:58.09

ゼロクリアする必要がない (から削除してよい) ことをコンパイラが見抜けないもんなのか？

**デフォルトの名無しさん** · 2025/05/22(木) 21:53:24.32

>>773
特定の使われ方するものに限って将来型システム拡張で対応できる可能性があるかもしれないらしいけど現状は無理だね
型Tの入る場所には型Tの何か入れておかないと未定義動作となってしまう
そこで現在はMaybeUninit型という初期化しなくていい型が用意されていてそれを使うことでCと同じ速さにできる

**デフォルトの名無しさん** · 2025/05/22(木) 22:18:19.76

Apple M3で8.8%遅かったのが7%になったとな
「5%遅い」はAMD Ryzenでの数字

**デフォルトの名無しさん** · 2025/05/23(金) 00:20:06.09

>>767
> なんでRustで作られたモノが極端に少ない
crateばっか作ってるなw

>>770
githubレポ数で割ると

Rust 21%
Python 5%
JavaScript 8%

Rustはこれで良いのか？

**デフォルトの名無しさん** · 2025/05/23(金) 00:34:18.82

>>720
静的解析ツールで検知できそうなもんだけどな
Rustにはないのかね？

**デフォルトの名無しさん** · 2025/05/23(金) 01:14:01.61

外部の状態が関係してるから静的解析では無理だろ

self.buffer.extract_raw(beg.offset, end.offset, &mut replacement, 0);
で取得したreplacementが長さ0である可能性とか分からん

**デフォルトの名無しさん** · 2025/05/23(金) 18:12:15.45

開発自体は別言語で行って最後にRustに移植で良い気がしてきた

**デフォルトの名無しさん** · 2025/05/23(金) 19:45:55.43

バカはそれでいい

**デフォルトの名無しさん** · 2025/05/23(金) 20:53:28.09

神は仰った
天才と思う者だけRustを使いなさい

Rustを使うものはバカだけになった

**デフォルトの名無しさん** · 2025/05/23(金) 20:55:45.35

バカは移植できないしRustも使えないだろ

**デフォルトの名無しさん** · 2025/05/23(金) 21:06:36.34

>>779
別言語って具体的に何？

**デフォルトの名無しさん** · 2025/05/23(金) 21:11:13.25

バカは別言語が気になる

**デフォルトの名無しさん** · 2025/05/23(金) 21:14:51.67

オレはTypeScriptで書いてたWEB APIをRustで書き直したよ
その後保守性わるくてTypeScriptに戻したけど
またRustで書き直そうかと迷ってる
性能か保守性か悩ましい

**デフォルトの名無しさん** · 2025/05/23(金) 21:20:15.08

保守性の高さからRustが使われる
Rustより保守性の高い言語はない

**デフォルトの名無しさん** · 2025/05/23(金) 21:25:40.65

プロトタイプはPythonでいいぞ

**デフォルトの名無しさん** · 2025/05/23(金) 21:48:17.92

GC言語などでメモリ関係なくコード書いて最後にRustでいいんじゃないか
asmの代わりがRust

**デフォルトの名無しさん** · 2025/05/23(金) 22:03:24.19

保守性高いと進化留まりガチ

**デフォルトの名無しさん** · 2025/05/23(金) 22:31:16.60

Rustの保守性の高さは並列排他に至るまで対応する強力な型システムがベース
進化を重ねていて両立

**デフォルトの名無しさん** · 2025/05/23(金) 23:00:21.91

体言止めおじ

**デフォルトの名無しさん** · 2025/05/23(金) 23:13:32.86

>>785
Rustの保守性の良し悪しはともかく、そんなしょっちゅう書き直せる程度のものなら保守性なんか気にする必要ないっしょ

**デフォルトの名無しさん** · 2025/05/23(金) 23:21:45.26

>>778
今回のは長さ0になる可能性があることが分かるやろ

はっきり分からないような場合でも解析ツール的にはフォルスポジティブでも安全側に倒しておいたほうがいいから「長さ0にならないとは断言できない」っというので警告を出す条件としては十分

**デフォルトの名無しさん** · 2025/05/24(土) 09:17:30.06

コンパイルが通れば安全じゃなかったの

**デフォルトの名無しさん** · 2025/05/24(土) 09:24:29.16

>>794
アホ？テスト通せよ

**デフォルトの名無しさん** · 2025/05/24(土) 09:42:12.79

>>794
安全だよ
この件でメモリのセキュリティのホールになることはない

**デフォルトの名無しさん** · 2025/05/24(土) 09:42:56.36

Rustでもほとんどのプログラミング言語と同じでインデックス境界チェックエラーにより落ちてくれる

**デフォルトの名無しさん** · 2025/05/24(土) 09:44:36.18

Rustでこれを避けるにはindex値が範囲内か不明の時はxxx[index]アクセスをしないこと
get*やイテレータなどを使う

**デフォルトの名無しさん** · 2025/05/24(土) 10:24:46.55

イテレーターとインデックスアクセスじゃスピード変わりそう
と言うより用途が違う

**デフォルトの名無しさん** · 2025/05/24(土) 10:39:58.90

末尾\0が保証されてるCのコードをそのまま移植したんでしょ
いわゆる「Rustは清書用」バグ

**デフォルトの名無しさん** · 2025/05/24(土) 11:01:12.40

たとえば「任意のコードを実行可能」な脆弱性が「異常終了するだけ」の実行時エラーで置き換えられる
この種類の置き換えはJavaでもできる

**デフォルトの名無しさん** · 2025/05/24(土) 11:12:53.59

>>800
C言語の段階で範囲外インデックスのバグだな
落ちなくてヤバかった

**デフォルトの名無しさん** · 2025/05/24(土) 11:25:25.71

>>800
関係ないやろ

**デフォルトの名無しさん** · 2025/05/24(土) 11:33:16.13

アクセス違反だがCでは落ちずに動いていた
Rustにしたことでバグが露呈

**デフォルトの名無しさん** · 2025/05/24(土) 11:58:41.99

>>795
このスレでさんざんコンパイル通れば安全という話を見てきたんですが

**デフォルトの名無しさん** · 2025/05/24(土) 12:00:21.23

ていうか、mutを制限しない限り、末尾\0は別の値に変更できるから末尾\0は保証されない

**デフォルトの名無しさん** · 2025/05/24(土) 12:06:04.95

>>805
コンパイルが通れば安全というのはRust-bookの翻訳の間違いな。原文読まないと
手を動かさないと理解できないだろうが、Rustにはテストフレームワークが組み込まれてるし、さらに外部のクレートを使うことが推奨される

cargo-nextest
cargo-insta
あたりね

ライブラリークレートをコーディングするときに並行してテストコードも書いて、バウンダリーズとかに問題がないことを確認した上でcrates.ioやgithubに公開しないと恥かくよ。上のヌル文字終端とかもCから来た人なら絶対テストに入れるべきよ

恥を気にしない人なら好きにしてくれ！

**デフォルトの名無しさん** · 2025/05/24(土) 12:24:06.94

>>805
Rustではコンパイラが通れば必ず安全が保証されるよ

**デフォルトの名無しさん** · 2025/05/24(土) 12:24:29.19

>>805
MSエディタはインデックス範囲外をpanicするAPIを使っていて安全に落ちていて他の言語と同じ

**デフォルトの名無しさん** · 2025/05/24(土) 12:26:01.00

>>805
Safe Rustに限定すればRust自身にバグがない限りは安全
今回のはpanicするだけなので安全の範疇だよ
「安全 == ロジックバグがないこと」だと思ってるならそれは間違い

**デフォルトの名無しさん** · 2025/05/24(土) 12:30:11.61

panicがイヤならpanicしないAPIを使えば解決するね
panicするAPIを使っておいてpanic違反するのはマゾみたいなもの

**デフォルトの名無しさん** · 2025/05/24(土) 12:45:05.58

>>803
Cの場合は空文字列でも\0があるから最初に
if (str[0] == '\t)
をぶつけても問題にならないよ
このフローをそのままRustに持ち込んだ感じ
もとのコード見れないから断言はできんが

**デフォルトの名無しさん** · 2025/05/24(土) 12:45:10.09

とっくに化けの皮は剥がれてるのに、こんな新規参入のない掲示板で耳障りのいいことばっかり書いて何になると思ってるんだろうか

**デフォルトの名無しさん** · 2025/05/24(土) 13:50:39.66

コード見たけどRustならスライスとそのメソッド使うところ
なぜかインデックスアクセス多いな
該当部の直後も
while remove < self.tab_size as usize
　&& offset + remove < replacement.len()
　&& replacement[offset + remove] == b' '
{
　remove += 1;
}

**デフォルトの名無しさん** · 2025/05/24(土) 14:01:45.35

最初に機能の弱い他の言語で書くからそうなる
最初から抽象的に書けるRustを使うべき

**デフォルトの名無しさん** · 2025/05/24(土) 14:17:39.59

えー、このクソ言語で？

**デフォルトの名無しさん** · 2025/05/24(土) 14:34:27.01

crates.ioの恥は描き捨て

**デフォルトの名無しさん** · 2025/05/24(土) 14:47:03.56

続けるだけでは意味がない。研究が示した「成長できない人の条件」
公開日2025.05.24 13:00:14 SATURDAY
http://nazology.kusuguru.co.jp/archives/177845

**デフォルトの名無しさん** · 2025/05/24(土) 15:05:18.87

古く機能が弱いプログラミング言語にこだわってる人は成長できない

**デフォルトの名無しさん** · 2025/05/24(土) 15:11:27.10

キラキラは個人の成長じゃなくて人類の進化なのに

**デフォルトの名無しさん** · 2025/05/24(土) 15:17:37.34

>>812
仮にCバージョンでTextBufferをnull終端した状態で管理していたとしてもreplacementはその一部分を指し示すものなのでnull終端したりはしないぞ

**デフォルトの名無しさん** · 2025/05/24(土) 15:21:29.32

null終端は部分文字列が作れないからそういう時には使わないよな

**デフォルトの名無しさん** · 2025/05/24(土) 16:45:23.89

>>821
コード見てないだろ

https://github.com/microsoft/edit/blob/main/src/buffer/mod.rs
のunindent()が何やってるか追えば対象の一部分を作業用の一時bufferに読み込んでるの分かるはず
エディタは履歴管理も必要だからね

**デフォルトの名無しさん** · 2025/05/24(土) 17:16:21.68

>>792
まだ本番運用前だからね
TypeScriptとかJavaScriptのホットリロード(pm2)がプログラム修正時にすごくありがたいんよ
でもRustで性能上がるのはわかりきってるから悩ましい

本番環境で実行中のプロセスは実行終了まで旧バージョンで動作させて
新たな処理は新バージョン用の新プロセスで実行してくれるようなRust用のしくみ(pm2のRust版みたいなの)ないのかな

**デフォルトの名無しさん** · 2025/05/24(土) 17:46:57.96

Common Lisp は実行性能が良くて抽象度も高いしホットリロードの本家みたいなもんだ。
だけどまぁ Lisp 系ってだけで敬遠するのが世間の普通だし、慣れが不十分だと何でも使い難いよ。

慣れてるのがやりやすいというだけの本当に単純な話なんで、
Rust 初心者が今まで使ってた言語より使い難い！ってのは言語の比較になってない。

**デフォルトの名無しさん** · 2025/05/24(土) 17:57:30.53

>>823
だからその読み込み先の一時bufferをnull終端させたりしないんだって
それに一時buffer使ってるのは履歴管理のためじゃないぞ

**デフォルトの名無しさん** · 2025/05/24(土) 18:01:36.37

そういや、一昔前は新しい言語が話題になれば必ずLispと比べて腐すのが作法だったのに
近頃は見なくなったな

**デフォルトの名無しさん** · 2025/05/24(土) 18:12:36.04

Rust はカテゴリとしてはシステムプログラミング言語だ。
C++ などに慣れている人が Rust 入門する分にはそんなにハードルは高くないと思う。
むしろ C++ 使いこそ Rust を賞賛しているケースが目につく。
C++ は必要なものは揃っている現実的な言語だが後付けだらけでグダグダだし、メモリアクセス関連で未定義を踏むのはベテランでもやることだからな……。
それが解決するなら大歓迎だ。

ウェブ系 (JavaScript, TypeScript) からだと Rust は色々と分かり難い要素が多そうだが、
ウェブ界隈で Rust の存在感が出てきてしまったから使わざるを得ないこともあるだろうし、
仕方なく使ってれば文句も出るんだろうと思ってる。

**デフォルトの名無しさん** · 2025/05/24(土) 18:24:31.95

OOP時代に耳障りのいいことが色々言われたおかげで
演算子や関数名を左端に書く時代は終わった
けど演算子は継承やvirtualでうまく表現できなかったからOOP時代も終わった

**デフォルトの名無しさん** · 2025/05/24(土) 20:46:05.09

>演算子や関数名を左端に書く時代

なにこれ

**デフォルトの名無しさん** · 2025/05/24(土) 21:37:14.29

>>830
たぶん LISP のことを言ってる。

**デフォルトの名無しさん** · 2025/05/24(土) 21:53:46.20

>>824
そんなBFFみたいなのをRustで書くのはあまり一般的ではないでしょ
普通にNextとかにしてパフォーマンスクリティカルな部分だけRustで書いてRPCかFFIで呼べばいいのでは？
どうせ君はやってみたいだけ俺スゲーしたいだけなんだから、その方が合理的な判断でRustを採用してるっぽくなって自尊心高まるぞ

**デフォルトの名無しさん** · 2025/05/24(土) 22:24:13.67

>>727
unindent関数で各行をreplacement.drain(offset..offset + remove)しているけど
indexを使わずにイテレーターでやる場合、更に追加のバッファが必要になる感じで良いのかな？

**デフォルトの名無しさん** · 2025/05/24(土) 22:57:52.90

>>814
安全に速くするにはこう？
remote += replacement[(offset + remote)..]
　.iter()
　.take_while(|b| **b == b' ')
　.take(tab_size as usize - remote)
　.count();

**デフォルトの名無しさん** · 2025/05/24(土) 23:12:04.53

spaceとtabが混ざっているとインデントレベルが破綻するね
例えば tab_width==4 で
space tab の並びはインデント1つ分

**デフォルトの名無しさん** · 2025/05/24(土) 23:12:54.11

unindent後も
tab の並びでインデント1つ分

**デフォルトの名無しさん** · 2025/05/24(土) 23:23:16.50

それは混ぜた人の問題だから仕様でいいだろ

**デフォルトの名無しさん** · 2025/05/24(土) 23:35:00.85

>>832
両方の言語で書いてみたあとそれも考えたけど
性能差の根本がhttpサーバ部分の性能差だからそうはいかないんよね

**デフォルトの名無しさん** · 2025/05/24(土) 23:39:02.86

>>837
そだね
スター沢山ついたけど細かい面倒を買って出る人は少ないよね

>>834
ちなみにspace/tab混在も対応する場合、オリジナルのループなら簡単な変更で、意図が明確だと思うけど
イテレーターだとごちゃつくのでは

>>727,833
これもごちゃつくのでは

**デフォルトの名無しさん** · 2025/05/25(日) 01:10:56.69

>>838
さすがにそのレベルだと完全に無意味なオーバーエンジニアリングだから、もう好きにしたらいいのでは

**デフォルトの名無しさん** · 2025/05/25(日) 01:44:17.05

どうせ君はやってみたいだけ俺スゲーしたいだけなんだから

見ず知らずの相手にここまでひどい人格否定ワード言われる筋合いはないぞ。追放かなこいつ

**デフォルトの名無しさん** · 2025/05/25(日) 04:45:11.33

メモリ保護以外にもなんかねーのか
もう一歩欲しいよな
型アノテーションもつけてくれ

**デフォルトの名無しさん** · 2025/05/25(日) 10:06:04.62

Web APIでhttpサーバ部分がボトルネックになるってどんな状況なんだろ
大量のIO待ちリクエストが発生するような状況ならあるかもしれないが、そんなの>>824みたいなゆるいスタイルで作るかなあ

**デフォルトの名無しさん** · 2025/05/25(日) 10:20:43.43

>>843
その>>824の人の状況は知らないけど
httpサーバ部分がRustとJavaScriptでは裁けるクライアント数が全然違うよ

**デフォルトの名無しさん** · 2025/05/25(日) 10:57:10.37

>>844
ffi等による部分的なRust化で効果がないってことは、838のいうhttpサーバーというのはhttpサーバーのミドルウェア部分(アプリケーションコードを含まない)のみを指してるはずで、
それがネックだとすると、レスポンスタイムの殆どをIOが占めていて、かつ同時処理されるリクエスト数がサーバー台数に対して無茶苦茶多いという極端な状況が考えられる
そんな状況なら一般的なWebアプリだったらDBのコストの方が遥かに高くつくんじゃないかなあ