我正在创建一个主要依赖于计时器的应用程序，
当计时器打勾我的应用程序将完成一项艰巨的任务;（我的任务经理说50％，在双核机器中，一个核心被完全使用）。 它在事件上创建了两个对象和17个变量。
我如何改善计时器事件的表现;以下是我的想法，请告诉我它是否会改善或恶化
我需要更多的idas来尽量减少定时器的间隔，并尽可能降低cpu的使用率
迟缓的主要原因是嵌套4个循环;但我没有任何删除或减少它们的原因
// ========================更新==================== =============================
感谢您的回复，我的应用会监控网络摄像头并在检测到动作时发出警报; 但对不起，我不能在这里发布我的代码;但我可以告诉你代码周围发生了什么
首先将图像分成25 * 25个图像; 2个循环用于此
存储件的平均颜色被重新存储并与当前颜色进行比较;这个
的2个循环然后应用程序将显示检测到动作的位置
计时器间隔当前设置为300
答案 0 :(得分：13)
创建2个类实例和17个变量将立即完成 - 在所有情况下，在比定时器分辨率更短的时间内完成。
所以你的计时器还有其他东西会烧掉你的CPU。数据访问，处理，计算。如果没有更多的信息和源代码，就无法猜测需要优化的是什么。
您需要的是个人资料您的应用。您在最新版本的Delphi中有AQTime，但您可以查看GPProfile或ProDelphi。如果需要，您可以使用profile-ready logging system like ours在客户端进行制作。然后你会看到什么是慢的，即大部分时间花在哪里。
使用带睡眠的循环（我认为在后台线程中）不会比计时器快。
恕我直言，快速重复任务是使用一些预先计算的表格。可能每次都不需要计算或检索一些数据。因此，您可以将这些数据存储在共享变量中，并在事件处理程序中使用它。始终认为更改算法或避免数据/硬件访问是速度的关键。并始终相信一个分析器，而不是你的第一直觉。更新后的问题
因此，您的问题与图片的处理时间直接相关。你仍然需要实际的分析来猜测应该改进什么。我想你在这个计时器中检索图片。网络摄像头图片的过程不会花费300毫秒。因此可能使用后台线程来检索网络摄像头图像，将它们推入循环列表，然后让计时器仅在被要求时处理最新图像。但是需要对代码进行真正的分析。
如果Delphi循环中的图片处理过程本身很慢，那么采样分析器将帮助您查看哪一行代码需要加速。在这种情况下的一些建议：
for x := xRef-3 to xRef+3 do.. - 主要规则是避免代码中的任何分支 - if ... then或{{1} }出现在你的代码中，越多越好; 答案 1 :(得分：4)
全局创建和初始化局部变量（声明它们 全局）：可能无济于事，但会使代码混乱。本地 变量访问并不昂贵。
并发//是否有可能 在德尔福做：可能，但在另外做错事 线程会占用CPU时间，就像在计时器中做错了一样 事件。更糟糕的是，你可能会创建更多的线程 一旦定时器在创建的线程之前重新触发 之前的计时器刻度已完成其工作
使用带睡眠的循环 函数而不是计时器：可能会产生相同的结果，并且 还会阻止用户界面，使您的应用响应性降低
如果您发布代码和计时器设置，以及计时器的要求（这导致您的特定计时器设置），我将更新答案，使其更具建设性。
**更新/加法**
没有看到任何代码我只能估计你可能有很多Windows API调用。您可以监视使用什么值进行哪些调用，使用相同的参数值集合来识别那些调用，以及缓存，或完全取消循环，结果计算。 （这与其他答案中的预备建议类似。）对于图像处理，颜色映射计算（调色板，本机 - > RGB转换等）是频繁的操作，可以通过用预先计算的查找表替换API调用来轻松优化。
如果您自己进行大多数计算/图像数据操作，您必须自己优化代码，其中包括使用“配置文件”中的建议。回答，或者，我建议，发布一些代码。
没有人可以诊断只有简要描述的有缺陷的机器。即使没有录制操作声音，也没有特定发动机细节的图片，所有机械师都可以说是“真的，有问题，但更多我不能说”如果你只是告诉他“它没有以预期的速度运行”
答案 2 :(得分：2)
将处理移动到单独的工作线程中。让一个线程从网络摄像头读取图像并将它们推入某个队列进行处理。让另一个线程（或线程池）处理队列。完成后，将最终结果发布到主线程以供显示。
答案 3 :(得分：1)
没有提升计时器“性能”的东西。计时器可以做到这一点，非常好，就是这样。
只能得出一个结论：您的代码需要300毫秒才能完成。配置文件和重构优化您的代码，或将计时器间隔设置为更大的值。