C# 投票有什么问题？

What is wrong with polling?

提问by HAdes

I have heard a few developers recently say that they are simply polling stuff (databases, files, etc.) to determine when something has changed and then run a task, such as an import.

我最近听到一些开发人员说他们只是轮询内容（数据库、文件等）以确定何时发生更改，然后运行任务，例如导入。

I'm really against this idea and feel that utilising available technology such as Remoting, WCF, etc. would be far better than polling.

我真的反对这个想法，并认为利用可用的技术，如Remoting、WCF等，会比轮询好得多。

However, I'd like to identify the reasons why other people prefer one approach over the other and more importantly, how can I convince others that polling is wrong in this day and age?

但是，我想找出为什么其他人更喜欢一种方法而不是另一种方法的原因，更重要的是，我如何说服其他人在这个时代投票是错误的？

采纳答案by xan

Polling is not "wrong" as such.

投票本身并没有“错误”。

A lot depends on how it is implemented and for what purpose. If you really care about immedatly notification of a change, it is very efficient. Your code sits in tight loop, constantly polling (asking) a resource whether it has changed / updated. This means you are notified as soon as you can be that something is different. But, your code is not doing anything else and there is overhead in terms of many many calls to the object in question.

在很大程度上取决于它的实施方式和目的。如果您真的很关心更改的即时通知，那么它非常有效。您的代码处于紧密循环中，不断轮询（询问）资源是否已更改/更新。这意味着您会尽快收到通知，发现情况有所不同。但是，您的代码没有做任何其他事情，并且在对相关对象的许多调用方面存在开销。

If you are less concerned with immediate notification you can increase the interval between polls, and this can also work well, but picking the correct interval can be difficult. Too long and you might miss critical changes, too short and you are back to the problems of the first method.

如果您不太关心立即通知，您可以增加轮询之间的间隔，这也可以很好地工作，但选择正确的间隔可能很困难。太长，您可能会错过关键更改，太短，您又会回到第一种方法的问题。

Alternatives, such as interrupts or messages, etc. can provide a better compromise in these situations. You are notified of a change as soon as is practically possible, but this delay is not something you control, it depends on the component tself being timely about passing on changes in state.

在这些情况下，诸如中断或消息等替代方案可以提供更好的折衷方案。您会在实际可能的情况下尽快收到更改通知，但是这种延迟不是您可以控制的，它取决于组件本身是否及时传递状态更改。

What is "wrong" with polling?

投票有什么“错误”？

• It can be resource hogging.
• It can be limiting (especially if you have many things you want to know about / poll).
• It can be overkill.

• 它可能是资源占用。
• 它可能会受到限制（特别是如果您想了解/投票的内容很多）。
• 这可能是矫枉过正。

But...

但...

• It is not inherently wrong.
• It can be very effective.
• It is very simple.

• 它本质上并不是错误的。
• 它可以非常有效。
• 这很简单。

回答by Robert Gould

Polling is easy to do, very easy, its as easy as any procedural code. Not polling means you enter the world of Asynchronous programming, which isn't as brain-dead easy, and might even become challenging at times.

轮询很容易做到，非常容易，就像任何程序代码一样简单。不轮询意味着您进入了异步编程的世界，这并不容易，有时甚至可能变得具有挑战性。

And as with everything in any system, the path of less resistance is normally more commonly taken, so there will always be programmers using polling, even great programmers, because sometimes there is no need to complicate things with asynchronous patterns.

与任何系统中的所有事物一样，阻力较小的路径通常更常见，因此总会有程序员使用轮询，即使是伟大的程序员，因为有时不需要使用异步模式使事情复杂化。

I for one always thrive to avoid polling, but sometimes I do polling anyways, especially when the actual gains of asynchronous handling aren't that great, such as when acting against some small local data (of course you get a bit faster, but users won't notice the difference in a case like this). So there is room for both methodologies IMHO.

我总是努力避免轮询，但有时我还是会进行轮询，尤其是当异步处理的实际收益不是那么大时，例如在处理一些小的本地数据时（当然你会更快一点，但是用户在这种情况下不会注意到差异）。所以恕我直言，这两种方法都有空间。

回答by Ali Afshar

This is not answering your question. But realistically, especially in this "day and age" where processor cycles are cheap, and bandwidth is large, polling is actually a pretty good solution for some tasks.

这不是在回答你的问题。但实际上，尤其是在这个处理器周期便宜且带宽大的“时代”中，轮询实际上是某些任务的不错解决方案。

The benefits are:

好处是：

• Cheap
• Reliable
• Testable
• Flexible

• 便宜的
• 可靠的
• 可测试
• 灵活的

回答by JeeBee

If you are polling for changes to a file, then I agree that you should use the filesystem notifications that are available for when this happens, which are available in most operating systems now.

如果您正在轮询文件的更改，那么我同意您应该使用发生这种情况时可用的文件系统通知，现在大多数操作系统都提供这些通知。

In a database you could trigger on update/insert and then call your external code to do something. However it might just be that you don't have a requirement for instant actions. For instance you might only need to get data from Database A to Database B on a different network within 15 minutes. Database B might not be accessible from Database A, so you end up doing the polling from, or as a standalone program running near, Database B.

在数据库中，您可以在更新/插入时触发，然后调用外部代码来执行某些操作。但是，可能只是您不需要即时操作。例如，您可能只需要在 15 分钟内将数据从数据库 A 获取到不同网络上的数据库 B。数据库 B 可能无法从数据库 A 访问，因此您最终从数据库 B 或作为在数据库 B 附近运行的独立程序进行轮询。

Also, Polling is a very simple thing to program. It is often a first step implementation done when time constraints are short, and because it works well enough, it remains.

此外，轮询是一个非常简单的编程事情。当时间限制很短时，它通常是第一步实施，并且因为它运行良好，所以它仍然存在。

回答by hopla

There are two reasons why polling could be considered bad by principle.

原则上可以将轮询视为不好的原因有两个。

1. It is a waste of resources. It is very likely that you will check for a change while no change has occurred. The CPU cycles/bandwidth spend on this action does not result in a change and thus could have been better spend on something else.

2. Polling is done on a certain interval. This means that you won't know that a change has occurred until the next time that the interval has passed.

1. 这是一种资源浪费。您很可能会在未发生任何更改时检查更改。在此操作上花费的 CPU 周期/带宽不会导致更改，因此本可以更好地花费在其他事情上。

2. 轮询是在特定时间间隔内完成的。这意味着直到下一次间隔过去后，您才会知道发生了更改。

It would be better to be notified of changes. This way you're not polling for changes that haven't occurred and you'll know of a change as soon as you receive the notification.

最好能收到更改通知。这样您就不会轮询尚未发生的更改，并且您会在收到通知后立即知道更改。

回答by James Anderson

The thing about polling is that it works! Its reliable and simple to implement.

关于投票的事情是它有效！它可靠且易于实施。

The costs of pooling can be high -- if you are scanning a database for changes every minute when there are only two changes a day you are consuming a lot of resources for a very small result.

池化的成本可能很高——如果您每分钟扫描一次数据库中的更改，而每天只有两次更改，那么您将消耗大量资源以获得非常小的结果。

However the problem with any notification technoligy is that they are much more complex to implement and not only can they be unreliable but (and this is a big BUT) you cannot easily tell when they are not working.

然而，任何通知技术的问题在于它们实施起来要复杂得多，而且它们不仅不可靠，而且（这是一个很大的 BUT）你无法轻易判断它们何时不工作。

So if you do drop polling for some other technoligy make sure it is usable by average programmers and is ultra reliable.

因此，如果您确实对某些其他技术进行了丢弃轮询，请确保它可供普通程序员使用并且非常可靠。

回答by James Anderson

Its simple - polling is bad - inefficient, waste of resources, etc. There is always some form of connectivity in place that is monitoring for an event of some sort anyway, even if 'polling' is not chosen.

它的简单 - 轮询很糟糕 - 效率低下，浪费资源等。总是有某种形式的连接在监视某种事件，即使没有选择“轮询”。

So why go the extra mile and put additional polling in place.

那么为什么要加倍努力并进行额外的投票。

Callbacks are the best option - just need to worry about tie the callback in with your current process. Underlying, there is polling going on to see that the connection is still in place anyhow.

回调是最好的选择 - 只需要担心将回调与您当前的进程联系起来。在底层，正在进行轮询以查看连接无论如何仍然存在。

If you keep phoning/ringing your girlfriend and shes never answers, then why keep calling? Just leave a message, and wait until she 'calls back' ;)

如果你一直给你的女朋友打电话/打电话，她从不接听，那为什么还要继续打电话？只需留言，然后等到她“回电”；）

回答by ljs

I agree that avoiding polling is a good policy. However, In reference to Robert's post, I would say that the simplicity of polling can make it a better approach in instances where the issues mentioned here are not such a big problem, as the asynchronous approach is often considerably less readable and harder to maintain, not to mention the bugs that can creep in to its implementation.

我同意避免投票是一项好政策。然而，参考罗伯特的帖子，我想说，在此处提到的问题不是那么大的问题的情况下，轮询的简单性可以使其成为一种更好的方法，因为异步方法通常可读性较差且难以维护，更不用说可能会潜入其实现中的错误。

回答by ljs

I use polling occasionally for certain situations (for example, in a game, I would poll the keyboard state every frame), but never in a loop that ONLY does polling, rather I would do polling as a check (has resource X changed? If yes, do something, otherwise process something else and check again later). Generally speaking though, I avoid polling in favor of asynchronous notifications.

我偶尔会在某些情况下使用轮询（例如，在游戏中，我会每帧轮询键盘状态），但从不在仅进行轮询的循环中，而是将轮询作为检查（资源 X 是否更改？如果是的，做一些事情，否则处理其他事情并稍后再检查）。不过一般来说，我避免轮询以支持异步通知。

The reasons being that I do not spend resources (CPU time, whatever) waiting for something to happen (especially if those resources could speed up that thing happening in the first place). The cases where I use polling, I don't sit idle waiting, I use the resources elsewhere, so it's a non-issue (for me, at least).

原因是我不会花费资源（CPU 时间，无论如何）等待某事发生（尤其是如果这些资源可以首先加速该事情的发生）。在我使用轮询的情况下，我不会闲着等待，我在其他地方使用资源，所以这不是问题（至少对我来说）。

回答by Valerion

As with everything, it depends. A large high-transaction system I work on currently uses a notification with SQL (A DLL loaded within SQL Server that is called by an extended SP from triggers on certain tables. The DLL then notifies other apps that there is work to do).

与所有事情一样，这取决于。我工作的一个大型高事务系统目前使用 SQL 通知（在 SQL Server 中加载的 DLL，由扩展 SP 从某些表上的触发器调用。然后 DLL 通知其他应用程序有工作要做）。

However we're moving away from this because we can practically guarantee that there will be work to do continuously. Therefore in order to reduce the complexity and actually speed things up a bit, the apps will process their work and immediately poll the DB again for new work. Should there be none it'll try again after a small interval.

然而，我们正在远离这一点，因为我们实际上可以保证会有工作持续进行。因此，为了降低复杂性并实际加快速度，应用程序将处理它们的工作并立即再次轮询数据库以获取新工作。如果没有，它会在一小段时间后再次尝试。

This seems to work quicker and is much simpler. However, another part of the application which is much lower volume does not benefit from a speed increase using this method - unless the polling interval is very small, which leads to performance problems. So we're leaving it as is for this part. Therefore it's a good thing when it's appropriate, but everybody's needs are different.

这似乎工作得更快，更简单。但是，应用程序的另一部分体积要小得多，使用此方法不会从速度提高中受益 - 除非轮询间隔非常小，这会导致性能问题。所以我们在这部分保持原样。所以合适的时候是好事，但每个人的需求都不一样。