unmanaged vs managed。 [英] unmanaged vs managed.
问题描述
很抱歉提出一个只会鞭打死马的话题....但是......
关于内存管理的话题......
我正在做一些必须尽可能快的文件分配，
但是我发现的并没有令人鼓舞...
我发现*最快的方法是使用一个结构来从文件中检索固定长度的
包，但结构放在堆栈上！在我读过的一本
书中，堆栈只有1mb左右，所以我宁愿不去那里。
（并不是说有足够的空间可以做我想要它做什么。）
如果我把所有的，比方说，5000多条记录单独放在堆上，那么每次堆都有很多工作量。必须要清洁。
所以最后，我看到两个好的剩余的选项：在托管堆上分配一块内存
，或在非托管堆上分配一块内存。从我读过的
，如果我在托管堆上分配一个块，然后想要
来使用指针，我肯定需要修复分配的内存通过
fixed（）或通过GCHandle固定。另一个选择是使用非托管内存。
我也读过pining会损害垃圾收集的过程，但是在另一本书中，我读了那个大的分配，而不是移动。
我的问题如下：
Q1）
使用固定或固定对象是一回事吗？（忽略事实上
在固定语句结束时内存被释放，并且当我说它时，
pinnin被取消固定。）任何使用pinning的好理由
固定??
Q2）
对于可能不会移动的对象固定所有坏处;无论如何？
Q3）
在这种情况下使用非托管内存会更好吗？
（是的我知道我会有要小心防止泄漏。）
Q4）
unmanage内存是否会移动？ （例如没有固定请求？）
Q5）
托管堆是否真的来自非托管？
如果是，一次有多少内存？并且是托管堆
从一端到另一端总是连续的？
Q6）
我听说泛型类list< Thas一些精彩的性能
增益，并且在堆上比ArrayList容易得多。大多数情况下，我听说它的性能提升是由于缺乏拳击和拆箱而导致的。
。是不是
它在堆上分配大块内存，防止zilions对象
浮动
也在托管堆周围？
Q7）
位图数据在堆上分配。为什么？
我听说过很多关于非管理堆的相互矛盾的故事，所以我是
提升
在黑暗中不知道真实"故事。
感谢您对此主题的任何和所有帮助。
Sorry to bring up a topic that is just flogging a dead horse.... but...
On the topic of memory management....
I am doing some file parcing that has to be done as quick as posible,
but what I have found hasnt been encouraging...
I found that the *quickest* way is to use a struct to retrieve fixed length
packets out of the file, but structs get placed on the stack! In one of the
books I read, the stack is only about 1mb, so I would rather it not go there.
(Not that there is even enough space to do what I want it to do.)
If I put all, say, 5000+ records on the heap individualy, then the heap has
to work quite hard every time it has to house cleaning.
So finaly, I see two "good" options remaining: Allocate one block of memory
on the managed heap, or a block of memory on the unmanaged heap. From
what I have read, if I allocate a chunk on the managed heap, and then want
to use pointers on it, I would definitly need to fix the allocated memory via
fixed() or pinning via GCHandle. The other option is to use unmanaged memory.
I have also read that pinning hurts the process of garbage collection, but in
another book, I read that big allocations typicaly dont get moved around.
My questions are as follows:
Q1)
Is using fixed or is pinning an object the same thing?(Ignoring the fact
that the memory is reliesed at the end of the fixed statement, and the
pinnin is unpinned when I say it is.) Any good reasons to use pinning over
fixed??
Q2)
Is pinning all that bad for an object that "probably won''t move" anyhow?
Q3)
Would using unmanaged memory be better in this case?
(yes I know that I would have to be careful to prevent leaks.)
Q4)
Does unmanage memory ever move? (eg no fixing req?)
Q5)
Does the managed heap actualy get derived from the unmanaged?
If so, how much memory at a time? and is the managed heap
always contiguous from one end to the other?
Q6)
I heard that the generics class list<Thas some wonderful performance
gains, and is a lot easier on the heap than the ArrayList. Mostly I have heard
that its performance gains are due to the lack of boxing and unboxing. Does
it allocate chunks of memory on the heap preventing zilions of objects
floating
around the managed heap too?
Q7)
"Bitmap data is allocated on the heap." Why?
I have heard so many conflicting stories about the unmanaged heap, so I am
lift
in the dark not knowing the "real" story.
Thank you for any and all your help on this topic.
推荐答案
TheMadHatter< Th**********@discussions.microsoft.comwrote：
TheMadHatter <Th**********@discussions.microsoft.comwrote:
很抱歉提出一个只是鞭打死马的话题......但是......
关于内存管理的话题......
我正在做一些必须尽可能快的文件分区，
但是我发现的并没有令人鼓舞...
我发现*最快的方法是使用结构来检索固定长度
包的文件，但结构放在堆栈上！在我读过的一本
书中，堆栈只有1mb左右，所以我宁愿不去那里。
（并不是说有足够的空间可以做我想要它做什么。）
如果我把所有的，比方说，5000多条记录单独放在堆上，那么每次堆都有很多工作量。必须清洁。
Sorry to bring up a topic that is just flogging a dead horse.... but...
On the topic of memory management....
I am doing some file parcing that has to be done as quick as posible,
but what I have found hasnt been encouraging...
I found that the *quickest* way is to use a struct to retrieve fixed length
packets out of the file, but structs get placed on the stack! In one of the
books I read, the stack is only about 1mb, so I would rather it not go there.
(Not that there is even enough space to do what I want it to do.)
If I put all, say, 5000+ records on the heap individualy, then the heap has
to work quite hard every time it has to house cleaning.
5000条记录不是很多。在你进行微优化
路由之前，你是否真的以最简单的方式编写了代码？
发现它肯定太慢了？我希望IO能够通过
*远*最慢的部分，很容易使GC时间相形见绌。
-
Jon Skeet - < sk *** @ pobox.com>
http：/ /www.pobox.com/~skeet 博客： http：// www .msmvps.com / jon.skeet
如果回复小组，请不要给我发邮件
5000 records is hardly a lot. Before you go down micro-optimisation
routes, have you actually written the code in the simplest way and
found that it''s definitely too slow? I would expect the IO to be by
*far* the slowest part, easily dwarfing GC times.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
当你说但我发现的并没有令人鼓舞 - 你的意思是
你已经创建了一个解决方案并对其进行了测试，你对
的结果感到不满意，或者你已经在做了一些阅读并且你不满意
你读过什么？
如果是后者，你可以尝试做你需要做的事情老管理
代码优先;你可能会发现结果很好。
- 彼得
递归：见递归
网站： http://www.eggheadcafe.com
unBlog： http://petesbloggerama.blogspot.com
BlogMetaFinder： http://www.blogmetafinder.com
" TheMadHatter"写道：
When you state "but what I have found hasnt been encouraging" -- do you mean
you''ve created a solution and tested it, and you are unhappy with the
results, or that you''ve been doing some reading and you aren''t happy with
what you''ve read?
If the latter, you might try doing what you need to do in plain old managed
code first; you may find the results are just fine.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com
"TheMadHatter" wrote:
很抱歉提出一个只是鞭打死马的话题....但是...
关于内存管理的主题....
我正在做一些必须尽可能快的文件分区，
但我发现的还没有鼓励...
我发现*最快*的方法是使用一个结构来检索固定长度
包的文件，但结构得到放在堆栈上！在我读过的一本
书中，堆栈只有1mb左右，所以我宁愿不去那里。
（并不是说有足够的空间可以做我想要它做什么。）
如果我把所有的，比方说，5000多条记录单独放在堆上，那么每次堆都有很多工作量。必须要清洁。
所以最后，我看到两个好的剩余的选项：在托管堆上分配一块内存
，或在非托管堆上分配一块内存。从我读过的
，如果我在托管堆上分配一个块，然后想要
来使用指针，我肯定需要修复分配的内存通过
fixed（）或通过GCHandle固定。另一个选择是使用非托管内存。
我也读过pining会损害垃圾收集的过程，但是在另一本书中，我读了那个大的分配，而不是四处走动。
我的问题如下：
Q1）
使用固定或固定物体相同事情？（忽略事实
在固定语句结束时释放内存，并且当我说它时，取消固定
pinnin。）任何好的理由使用固定在
固定??
Q2）
对于可能赢了的对象固定不好'不动'无论如何？
Q3）
在这种情况下使用非托管内存会更好吗？
（是的我知道我会有要小心防止泄漏。）
Q4）
unmanage内存是否会移动？ （例如没有固定请求？）
Q5）
托管堆是否真的来自非托管？
如果是，一次有多少内存？并且是托管堆
从一端到另一端总是连续的？
Q6）
我听说泛型类list< Thas一些精彩的性能
增益，并且在堆上比ArrayList容易得多。大多数情况下，我听说它的性能提升是由于缺乏拳击和拆箱而导致的。
。是不是
它在堆上分配大块内存，防止zilions对象
浮动
也在托管堆周围？
Q7）
位图数据在堆上分配。为什么？
我听过很多关于非管理堆的相互矛盾的故事，所以我是
电梯
在黑暗中没有知道真实的故事。
感谢您对此主题的任何和所有帮助。
Sorry to bring up a topic that is just flogging a dead horse.... but...
On the topic of memory management....
I am doing some file parcing that has to be done as quick as posible,
but what I have found hasnt been encouraging...
I found that the *quickest* way is to use a struct to retrieve fixed length
packets out of the file, but structs get placed on the stack! In one of the
books I read, the stack is only about 1mb, so I would rather it not go there.
(Not that there is even enough space to do what I want it to do.)
If I put all, say, 5000+ records on the heap individualy, then the heap has
to work quite hard every time it has to house cleaning.
So finaly, I see two "good" options remaining: Allocate one block of memory
on the managed heap, or a block of memory on the unmanaged heap. From
what I have read, if I allocate a chunk on the managed heap, and then want
to use pointers on it, I would definitly need to fix the allocated memory via
fixed() or pinning via GCHandle. The other option is to use unmanaged memory.
I have also read that pinning hurts the process of garbage collection, but in
another book, I read that big allocations typicaly dont get moved around.
My questions are as follows:
Q1)
Is using fixed or is pinning an object the same thing?(Ignoring the fact
that the memory is reliesed at the end of the fixed statement, and the
pinnin is unpinned when I say it is.) Any good reasons to use pinning over
fixed??
Q2)
Is pinning all that bad for an object that "probably won''t move" anyhow?
Q3)
Would using unmanaged memory be better in this case?
(yes I know that I would have to be careful to prevent leaks.)
Q4)
Does unmanage memory ever move? (eg no fixing req?)
Q5)
Does the managed heap actualy get derived from the unmanaged?
If so, how much memory at a time? and is the managed heap
always contiguous from one end to the other?
Q6)
I heard that the generics class list<Thas some wonderful performance
gains, and is a lot easier on the heap than the ArrayList. Mostly I have heard
that its performance gains are due to the lack of boxing and unboxing. Does
it allocate chunks of memory on the heap preventing zilions of objects
floating
around the managed heap too?
Q7)
"Bitmap data is allocated on the heap." Why?
I have heard so many conflicting stories about the unmanaged heap, so I am
lift
in the dark not knowing the "real" story.
Thank you for any and all your help on this topic.
" TheMadHatter" < Th ********** @ discuss.microsoft.comwrote
"TheMadHatter" <Th**********@discussions.microsoft.comwrote
我正在做一些必须尽快完成的文件分区，
但是我发现的并没有令人鼓舞...
我发现*最快的方法是使用结构来检索固定的
长度
文件包，
I am doing some file parcing that has to be done as quick as posible,
but what I have found hasnt been encouraging...
I found that the *quickest* way is to use a struct to retrieve fixed
length
packets out of the file,
你是过早优化的罪魁祸首。解析和执行
内存管理所花费的时间只是花在寻找和读取磁盘上所花费的时间的一小部分。
这应该是一个5或10行程序，99.99％的时间将是
磁盘I / O.
如果你为了它的乐趣，我想把事情变得复杂，使用
异步I / O（BeginRead等）。至少在提高应用程序性能方面有一定的合法性。
从长远来看，你还会考虑其他事情......
-
Chris Mullins
You''re guilty of premature optimization. The time spent parsing and doing
memory management is going to be a tiny fraction of the time spent doing
disk seeks and reads.
This should be a 5 or 10 line program, and 99.99% of the time is going to be
disk I/O.
If you want to make things needlesly complex just for the fun of it, use
Async I/O (BeginRead, etc). That at least has a measure of legitimacy behind
it in terms of improving application performance. It''ll also be more
educational in the long run that the other things you''re thinking about...
--
Chris Mullins
这篇关于unmanaged vs managed。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
