c#中list<T>的性能优化 List<T> 不是流,根本不按流的方式处理。MemoryStream 才是流。 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 你先进先出那就是Queue先进后出就是Stack然后你所谓的用了很长的时间,这个能具体化么? 取决于你的value,如果实现了ICollection,则内部的步骤是:1.根据value.count修改list容量至合适大小2.调用Array.Copy进行块复制这种情况下效率会很高如果不是,则枚举迭代器,逐个添加,如果value比较大,自然就慢了 所以你的建议是直接用MemoryStream来代替list<byte>? 性能好的方式是尽量不进行内存复制,但是你无论使用List<byte>还是MemoryStream都会进行复制,性能都会下降。(动态增长还会导致额外的复制)理想的情况是你能实现无需中间buffer,直接使用原始的数据/缓冲区。不行的话,自行实现一个Stream,内部把获取到的一块块数据使用链表串起来,添加数据块的时候就是增长这个链表,读的时候实现逻辑来让使用者感觉和读一个完整的数据一样。具体的方式和数据块的大小、个数、还有是否知道数据量等等因素相关。 用(byte[] or byte*)首先在内存中划分一块足够大的 buffer 我不推荐你用 byte[] 我比较推荐你使用byte* 用 stackalloc / heapAlloc 分配 因为你的操作单位是byte所以用指针+固定长度的数组自己构造一个队列比较好。 似乎C#里面没有vector这种数据结构,像vector的话就是占用超出初始空间时,将占用空间翻倍 问题是这玩意是c#代码,我该咋用指针呢如果C#能像C++那样直接操作内存的话就好了 在研究明白业务之前,不要纠结底层原理byte数组根本不应该出现"慢"的问题如果你说它"慢",那么必然是因为:1.你在其他的地方处理速度太慢,跟用什么来存无关2.你所谓的"快"要求太高,用台式机根本实现不了,你需要一个"银河"计算机 问题是这玩意是c#代码,我该咋用指针呢如果C#能像C++那样直接操作内存的话就好了可以使用指针, 使用unsafe 代码 谢谢,看来提高性能需要使用C#里面的unsafe编程,但现在有个问题就是我的数据结构非常复杂,只有在处理完以后,byte*的总长度才可以知道,所以需要有类似C++ vector的自动变长机制来处理,不知道byte[]有没有什么方法可以来延展长度的? 我考虑可以用list<byte[]>这样的方式来进行延展.byte[]的长度我可以指定为1024但有个比较蛋疼的问题就是,我在往里面填数据的时候,如果填到每个byte[]的末尾比如还剩1个字节,而我要填入的数据则是有4个字节那就必然要把这4个字节分成1个字节+3个字节这样来进行写入了解析的时候处理也不太好写 不能一次性分配这么大的空间,因为上层传入的数据大小不固定有可能是25k的图片数据,也有可能是8M以上的图片数据有时也可能会是一个非常小的Command List<ArraySegment<byte>>可否?可以指定每个byte[]的偏移量 我想了下,这种方法可能也会有问题,我们那个系统是个多线程系统,这么多线程公用一个buff的话势必涉及到锁的问题 我想了下,这种方法可能也会有问题,我们那个系统是个多线程系统,这么多线程公用一个buff的话势必涉及到锁的问题既然是多线程,不要多线程共用一个buff 现在试下来MemoryStream的性能跑同样的业务流程是之前list<byte>的两倍以上这个性能数据应该算是达标了明天再试试unsafe的写法 不知道 楼主 纠结 这点性能作甚。直接把 1.5G 的 电影文件,写入 内存 byte[] 或 MemoryStream 的飘过 —— 耗时只要 10秒钟。 问个 怎么导入邮件联系人的列表 的原理 给数据库查询出来的结果添加一个自增长的字段 关于DataGridView的选择问题 datagridview修改更新数据库 请教一个线程问题! api问题 c# 多线程 C# Winform应用程序与C#写的DLL间结构的传递 关于开机就运行程序的问题 放分,http://community.csdn.net/Expert/topic/4400/4400729.xml?temp=.7461969 WPF画了10w条线,图像可以展示,但是保存到png文件时,提示“图像尺寸超过此编码解码器支持的范围”? 关于HelpProvider的使用方式
先进后出就是Stack然后你所谓的用了很长的时间,这个能具体化么?
1.根据value.count修改list容量至合适大小
2.调用Array.Copy进行块复制
这种情况下效率会很高
如果不是,则枚举迭代器,逐个添加,如果value比较大,自然就慢了
所以你的建议是直接用MemoryStream来代替list<byte>?
用(byte[] or byte*)
首先在内存中划分一块足够大的 buffer
我不推荐你用 byte[] 我比较推荐你使用
byte* 用 stackalloc / heapAlloc 分配
所以用指针+固定长度的数组自己构造一个队列比较好。
问题是这玩意是c#代码,我该咋用指针呢
如果C#能像C++那样直接操作内存的话就好了
byte数组根本不应该出现"慢"的问题如果你说它"慢",那么必然是因为:
1.你在其他的地方处理速度太慢,跟用什么来存无关
2.你所谓的"快"要求太高,用台式机根本实现不了,你需要一个"银河"计算机
问题是这玩意是c#代码,我该咋用指针呢
如果C#能像C++那样直接操作内存的话就好了可以使用指针, 使用unsafe 代码
谢谢,看来提高性能需要使用C#里面的unsafe编程,但现在有个问题就是我的数据结构非常复杂,
只有在处理完以后,byte*的总长度才可以知道,所以需要有类似C++ vector的自动变长机制来处理,不知道
byte[]有没有什么方法可以来延展长度的?
list<byte[]>这样的方式来进行延展.
byte[]的长度我可以指定为1024
但有个比较蛋疼的问题就是,我在往里面填数据的时候,如果填到每个byte[]的末尾
比如还剩1个字节,而我要填入的数据则是有4个字节
那就必然要把这4个字节分成1个字节+3个字节这样来进行写入了
解析的时候处理也不太好写
不能一次性分配这么大的空间,因为上层传入的数据大小不固定
有可能是25k的图片数据,也有可能是8M以上的图片数据
有时也可能会是一个非常小的Command
我想了下,这种方法可能也会有问题,我们那个系统是个多线程系统,这么多线程公用一个buff的话势必涉及到锁的问题
既然是多线程,不要多线程共用一个buff
这个性能数据应该算是达标了
明天再试试unsafe的写法