REQ：对静态对象列表的高性能访问< string> [英] REQ: High Performance Access to a Static Object's List<string>

问题描述

你好，


有问题的应用程序存在于运行.NET 2.0的Windows 2003服务器上

IIS 6.应用程序的页面问题进程2000在高峰负载期间获得请求一秒

。


应用程序使用静态对象。在此对象中是一个通用List< String>。对于

每个页面请求这个列表只是读取不写每个

的值。


问题是，它会是在循环之前创建List

的副本的更好的做法是什么？

List< stringmyList = MyStaticObject.myList;如果这只是一个参考？如果

如此，那么它似乎效率会降低？如果这是真的，那么深度克隆列表然后循环会更好吗？


在压力加载下对dev机器进行测试hasn'没有任何关于

的最佳实践方法，以达到最佳效率。


提前感谢您的想法。


M

解决方案

List< stringmyList = MyStaticObject.myList;

如果这只是一个参考？如果是这样，那么它似乎效率会降低？

如果这是真的，深度克隆列表然后循环会更好吗？

如何降低效率？只要内容

不会偶尔改变（因此锁定是一个问题），那么深度

克隆只能增加时间。

从技术上讲，我相信一个字符串[]比一个

List< string>稍微快一些，所以也许换掉它？但是 - 更好的是查看一个分析器，看看你的时间在哪里。在一个字符串[]上，我相信（IIRC）索引器的访问权限再次/略微/更快 - 但是你的b / b
自己的测试可能有所帮助。

Marc

如何降低效率？


如果它'' sa参考然后为什么要创建一个新列表？我只是直接遍历

静态对象的列表。


最大并发性是我正在努力的。如果只有N个请求

可以读取静态对象的列表，那么我想知道是否复制了

列表会更快地释放读取另一个请求使用。

否则读取保持在循环期间保持有效。然后请问

问题，创建副本会消耗更多CPU，从而否定

任何收益。

Mark S.写道：

>如何降低效率？

如果它是一个参考，那么为什么要创建一个新列表？我只是直接遍历

静态对象的列表。

好​​吧，复制到局部变量的一个原因是静态

对象的引用可以由一个更新线程没有影响另一个人使用的

实例。


这将假设列表实例本身是不可变的，因为我

在我的其他回复中建议。


如果列表的更改总是存在，那么，是的......你需要

同步访问到列表中，至少只有在没有其他线程试图从中读取时才会写入

列表。


更容易是同步所有访问列表，但随后甚至

列表的读者将最终序列化，这可能会阻碍

的表现。这是一个经典的权衡......简单和优化并不总是相同的。 :)

最大并发性是我正在努力的目标。如果只有N个请求

可以读取静态对象的列表，那么我想知道是否复制了

列表会更快地释放读取由另一个请求使用。

在某种程度上，这取决于你在阅读过程中做了什么。如果

列表中的每个元素在

迭代期间需要大量时间来处理，那么复制列表可能会加快速度。

但是，如果您执行浅层复制，您可能仍然会在各个

列表元素之间出现同步问题，或者您可能没有发现任何

重要的性能优势如果你做了深层复制。

否则读取保持在循环期间保持有效。然后请问

问题，创建副本会消耗更多的CPU从而否定

任何收益。

只有通过测量它才能确定。这一切都取决于深度拷贝的价格是多少，无论你是否需要深层拷贝，以及

如何实际使用该列表所涉及的工作。


就个人而言，我会选择不可变的列表设计，但是因为我已经两次提到它，所以可能已经很明显了。 :)我

认为，至少每次更改时都会复制列表

（如果列表实例本身是不可变的则需要）是可能比复制它更有效。


Pete

Hello,

The app in question is lives on a Windows 2003 server with .NET 2.0 running
IIS 6. The page of the app in question processes 2000 get requests a second
during peak loads.

The app uses a Static Object. In this object is a generic List<String>. For
every page request this list is looped over only reading not writing each
value.

Question is, would it be a better practices to create an copy of the List
before looping over it?
List<stringmyList = MyStaticObject.myList; If this is just a reference? If
so, then it would seem to be less efficient? If that''s true, would it be
better to deep clone the list and then loop?

Testing on the dev machine under stress loading hasn''t shown any light on
the best practices way to go to reach optimal efficiency.

Thank you in advance for your thoughts.

M

解决方案

List<stringmyList = MyStaticObject.myList;

If this is just a reference? If so, then it would seem to be less efficient?
If that''s true, would it be better to deep clone the list and then loop?

How would that make it any less efficient? As long as the contents
aren''t changing occasionally (so that locking is an issue) then a deep-
clone can only add time.
Technically, I belive a string[] is marginally quicker than a
List<string>, so perhaps swap for that? However - better is to look at
a profiler and see where your time is really going. On a string[], I
believe (IIRC) indexer access is again /marginally/ quicker - but your
own tests may help.

Marc

How would that make it any less efficient?

If it''s a reference then why create a new list? I''d simply loop over the
static object''s list directly.

Maximum concurrency is what I''m striving for. If only N number of requests
can read the static object''s list then I was wondering if making a copy of
the list would more quickly release the read to be used by another request.
Otherwise that read hold stays in effect during the loop. Which then begs
question, does the creating the copy consume more the CPU thereby negating
any gains.

Mark S. wrote:

>How would that make it any less efficient?

If it''s a reference then why create a new list? I''d simply loop over the
static object''s list directly.

Well, one reason to copy to a local variable would be so that the static
object''s reference could be updated by one thread without affecting the
instance being used by another.

This would assume that the list instances themselves are immutable, as I
suggested in my other reply.

If changes to the list are always in place then, yes...you''ll need to
synchronize access to the list so that, at a minimum, writing to the
list only occurs when no other thread is also trying to read from it.

Easier would be to synchronize all access to the list, but then even
readers of the list would wind up serialized, which could hinder
performance. It''s a classic trade-off...easy and optimal are not always
the same. :)

Maximum concurrency is what I''m striving for. If only N number of requests
can read the static object''s list then I was wondering if making a copy of
the list would more quickly release the read to be used by another request.

To some extent, that depends on what you''re doing during the read. If
each element of the list requires extensive time to process during the
iteration then it''s possible copying the list could speed things up.
However, you may still have synchronization issues between individual
list elements if you do a shallow copy, or you may not find there''s any
significant performance benefit if you do a deep copy.

Otherwise that read hold stays in effect during the loop. Which then begs
question, does the creating the copy consume more the CPU thereby negating
any gains.

Only by measuring it will you know for sure. It all depends on how
expensive a deep copy is, whether you even need a deep copy, and how
much work the actual use of the list involves.

Personally, I''d go for the immutable list design, but then that''s
probably already apparent since I mentioned it twice already. :) I
think that, at the very least, copying the list each time it changes
(which would be required if the list instance itself is immutable) is
likely to be much more efficient than copying it each time you actually
use it.

Pete

这篇关于REQ：对静态对象列表的高性能访问&lt; string&gt;的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！