便利なツール・ソフトを作るスレ Ver.18

724：(･ω･)：2020/08/01(土) 15:24:11 ID:0dfdQIAw: Launcher と Radar は（textsの実行側の効率が上がって結果的に）結構無駄が無くなってるかも

以下独り言？extlibsのcolorstringbuilder.lua参照
行単位で合理化する従来のbuild_colorline～とは別物
例の「全ての行が色付きの文字で始まっていると横方向の表示開始位置がバグる」問題を回避しながら
色のエスケープを極力減らす為の仕組み

前者は行は意識せずにエスケープする必要がない時は\csを出力しない様にするだけの代物
後者はバグを回避したかどうかを判断しつつ行単位で必要のない\csを出力しない様にする為の代物
前者の方が汎用的な反面、バグは利用側が回避しなければならない、文字列の追加毎にオーバーヘッドが発生する、
複数のtextsに似た様な文字列を出力したり、出力を振り分けたりする場合にはかなり不向き
後者は行の文字列を作る時に文字列同士を結合する場合（大抵結合する）、
それらを更に結合するからメモリの複写の回数も２倍になってオーバーヘッドが大きい

でもって言うまでもないとは思うけど、文字列の実体の確保が実際に行われるという事は
ヒープの確保が行われるのが確定する（可変長だからC,C++でもそうなる）
内部で直接mallocやnew等をせずに、小さなヒープや文字列専用の独自のアロケータを使ってるにしても自動変数より遥かに遅い
GC積んでると早く見える事もあるけど、メモリ開放や各変数の被参照のチェックの類の処理時間は直接見えない
更にJITコンパイラの類を積んでない以上、やたらローカル変数やリテラルの文字列（リテラルに見える）を
分離したりサブルーチン化クラス化して綺麗にわかりやすく見えればいいってもんじゃない
ループにしてなかったりサブルーチン化してなかったりわざわざ冗長にスペース有り無しを並べてたり
無駄が多い様に見えるけど、下手に合理化すると遅くなるかも知れないから、いじる人は注意

※書き込む際の注意事項はこちら

※画像アップローダーはこちら

（画像を表示できるのは「画像リンクのサムネイル表示」がオンの掲示板に限ります）