文字列連結パフォーマンス

[Cユーザー]

文字列と数字を連結させる最速の処理を探しています。
現在検証したのは

・sprintf
・_itoa_s + strcat

他にこれ以上早く処理ができる方法ないでしょうか

[softya（ソフト屋)]

文字列と数字を連結させる最速の処理を探しています。
現在検証したのは

・sprintf
・_itoa_s + strcat

他にこれ以上早く処理ができる方法ないでしょうか

何のために必要な処理でしょうか？　普通は考える必要のない処理だと思います。
ただ、汎用関数に頼らないほうが速いのは確かです。

[へにっくす]

何がしたいんでしょうね？
マイコン８ｂｉｔの世界ならともかく、
いまどきのパソコンで文字列連結に対するパフォーマンスをみる必要があるのかな？

それに実際にコード組んで、何秒かかったか調べたのかいな？
（まあ秒なんてかからないと思うけど）
もし１秒以上かかるのであれば、そのコード、実行したＰＣのスペックなどを掲示するのが筋です。
その上で、これ以上早くなる処理がないか聞くべきです。

[Cユーザー]

いやそりゃ確かに1秒はかからないですけど
何万回も繰り返せば差がでます

何の為にとか奇妙な質問されますが
パフォーマンス向上の為としかいいようがありません。

[h2so5]

何の為にとか奇妙な質問されますが
パフォーマンス向上の為としかいいようがありません。

現在の実装では仕様上要求される時間内に処理を完了できないなど、パフォーマンスに関係する問題が存在しているのでしょうか。

[softya（ソフト屋)]

いやそりゃ確かに1秒はかからないですけど
何万回も繰り返せば差がでます

何の為にとか奇妙な質問されますが
パフォーマンス向上の為としかいいようがありません。

なぜ、こんなことを聞くかと言うと、必要もない所でパフォーマンスにこだわりイレギュラーなコードを書くプログラマーは、悪いプログラマーに分類されるからです。
【補足】　正確には質の悪いコードを書くプログラマーですかね。

[Cユーザー]

言いたいことはわからないでもないですが
私をしては処理の高速化は必要だから質問しており
それが必要かどうかってのは私の立場ではないとわからないことでは？

どう答えていいのかがわからない

[softya（ソフト屋)]

言いたいことはわからないでもないですが
私をしては処理の高速化は必要だから質問しており
それが必要かどうかってのは私の立場ではないとわからないことでは？

どう答えていいのかがわからない

どうしてもと言うなら
１．高速化するなら、とりあえず、汎用関数は使いません。
２．数値の文字列変換は自分で書きます。
３．２の時の最後のポインタ位置を覚えておいて、そのポインタ位置に文字列をコピーします。これも自分で書きます。strcpyでも同じアセンブラコードが出るならそちらを使います。
４．２と３はアセンブラコードの出力を見ながらコードをチューニングします。

[Cユーザー]

h2so5さん

>現在の実装では仕様上要求される時間内に処理を完了できないなど、パフォーマンスに関係する問題が存在しているのでしょうか

いやそういうわけではないんですが
処理の高速化を求めています。

[たいちう]

> 何の為にとか奇妙な質問されますが
> パフォーマンス向上の為としかいいようがありません。

回答者が聞き返している質問を、奇妙と思っているのですよね？
今時のPCならば何万回繰り返したところで、体感できる差は出ません。
パフォーマンスが悪いならばプログラムの他の部分が理由である可能性が高いです。

例えば、文字列を結合する処理よりも、文字列を表示する処理の方が桁違いに遅いですよ。

文字列結合が本当に必要だとしたら答えは出てますよね。
softyaさんの書いているとおり、専用の処理を作ればよいのです。

(何故か投稿に失敗したので再投稿。重複してたら削除お願いします)

[Cユーザー]

専用の処理ですね
なるほど検討しています。


To たいちうさん

ちょっと認識が合ってないと思います。例えば、現場リーダーからここの処理遅いから早くできないか、最速にしてほしいと言われたときに
体感では変わらないからとは言えません。数字を提示してこれが最速だからこれでいきます、と言う必要があります。
今回のもちょっと違いますけど似たような境遇です。なので、ここの処理をできるだけ早くする必要があります。

最初からこういえば理解してもらえたかな

[Cユーザー]

すいません、一旦解決にさせていただきます。

[softya（ソフト屋)]

専用の処理ですね
なるほど検討しています。


To たいちうさん

ちょっと認識が合ってないと思います。例えば、現場リーダーからここの処理遅いから早くできないか、最速にしてほしいと言われたときに
体感では変わらないからとは言えません。数字を提示してこれが最速だからこれでいきます、と言う必要があります。
今回のもちょっと違いますけど似たような境遇です。なので、ここの処理をできるだけ早くする必要があります。

最初からこういえば理解してもらえたかな

たいちうさんが書いたようにファイル出力などが一番遅いので、出力処理を非同期にしてその時に文字列を結合すれば結合の処理時間は相殺される可能性が高いです。
なので、最適解は処理途中は結合しないで使うのが一番早いかもしれません。そこだけ見た時と全体を見た時の答えは違う可能性があるので単純な高速化は意味が無いかもしれませんよね。そこまで考えているんでしょうか？と言う皆さんの問いかけなのです。

[Cユーザー]

なるほど、ありがとうございます。
その件も含めて再検討します

[softya（ソフト屋)]

仕事上で、どうしても止む負えない場合以外で、私の回答の様なアセンブラコードレベルでチューニングしたコードを書いてきたら、メンテンナンス性が悪いからとやり直しを命じるでしょう。
まず、見直すべきのは全体の仕様レベル、アルゴリズムレベルでの無駄がないかです。
文字列の結合など行わずに済むなら文字列の結合は時間の無駄以外の何物でもないので、文字列の処理を極力無くす方向に転換すべきでしょう。

[Ryo]

本当にこのレベルでの高速化を検討する気あるなら
実行環境などの情報が必要ではないでしょうか？

[softya（ソフト屋)]

本当にこのレベルでの高速化を検討する気あるなら
実行環境などの情報が必要ではないでしょうか？

_itoa_sが出てくる時点でほぼ間違いなくVisualStudioの環境と思われますが、Windowsで文字列結合にそこまでチューニングをする必然性が分からないんですよね。
時間が掛るのが嫌ならスレッドに分離すれば良いじゃないかとか、全体を見れば手はいくらでもありそうだと思うんですよね。

[Ryo]

マイクロソフトの推奨してるCRTセキュリティでしたね
気づけませんでした。