13/03/28 21:51:55.24
特に比べる気もないので、帰っていいよ
114:デフォルトの名無しさん
13/03/28 21:52:40.25
私の記憶が正しければBinaryFormatterの話だったと思うのですが…
115:デフォルトの名無しさん
13/03/28 21:53:25.91
XmlSerializer意外に優秀だなぁ
BinaryFormatterのデシリアライズおせえなぁ
って感想しか出ないな
116:デフォルトの名無しさん
13/03/28 21:53:49.70
圧倒的な結果を見ることもせず馬鹿が現実逃避を始めました。
117:デフォルトの名無しさん
13/03/28 21:54:05.10
世間の常識とか、MSの認識とか、そんなもの興味ないす
118:デフォルトの名無しさん
13/03/28 21:55:31.28
シリアライザっていうのは基本的に通信用なので、
シリアル化の速度なんかよりサイズを抑えることの方が重要
XmlSerializerはXML文書を扱うことに主眼が置かれているのでいわゆるシリアライザとはちょっと違うが
119:デフォルトの名無しさん
13/03/28 21:55:43.55
そんなヘンテコな状況のパフォーマンスなんてどうでもいー、という人は、各シリアライザの基本的な使いかたの参考にでもしてください
120:デフォルトの名無しさん
13/03/28 21:56:31.82
XmlSerializerが速く見えるのは失敗してnewしてないから。勘違いしないように。
121:デフォルトの名無しさん
13/03/28 21:58:36.67
見てもいないから勘違いしようがない
122:デフォルトの名無しさん
13/03/28 21:59:10.43
そもそもXmlSerializerをBinaryFormatterやDataContractSerializerと比べるのが間違い。
XmlSerializerと比べるなら役割的にはXML DOMやLINQ to XMLだろ。
123:デフォルトの名無しさん
13/03/28 22:03:47.31
>>118
通信ってのはプロセス間通信も含まれるし、外部記憶装置に対しても読み書きする。
普通はバイナリのままでサイズは小さい。さらに圧縮するのはかなり特殊。
124:デフォルトの名無しさん
13/03/28 22:06:55.96
実装者が落とし穴に気をつけなきゃいけないようなものをセキュアだなんだと言って欲しくない
可能なら、頑張っても落とし穴に落ちることができない仕組みにすべきなんだから
125:デフォルトの名無しさん
13/03/28 22:07:17.11
誤爆した
126:デフォルトの名無しさん
13/03/28 22:10:02.31
で、WCFのシリアライザで何の問題が?
君の好きなバイナリにも対応してるし起動も遅くならないし動作も速いよ
127:デフォルトの名無しさん
13/03/28 22:10:51.24
何の問題もないことは使う積極的な理由にはならんのです
128:デフォルトの名無しさん
13/03/28 22:11:20.71
要件が2.0なのです。
129:デフォルトの名無しさん
13/03/28 22:13:20.94
引導が渡った所で寝ましょう
130:デフォルトの名無しさん
13/03/28 23:59:47.47
XML厨が作ったBinaryFormatterとXmlSerializerは欠陥品です。
改良されたのがDataContractSerializerなのでそちらを使ってください。
131:デフォルトの名無しさん
13/03/29 00:08:00.89
ファイルサイズドン！さらに倍！
132:デフォルトの名無しさん
13/03/29 17:01:08.34
>>37
この程度のものさ。
URLﾘﾝｸ(bbs.wankuma.com)
133:デフォルトの名無しさん
13/03/31 22:27:38.62
ECMA-335のCLI仕様書って.NET4相当?
最終更新がJune 2012ってなってるけど