我们有一个在 VxWorks 5.5.1 上运行的相当大的应用程序，该应用程序已经开发和修改了大约 10 年。 我们有一些简单的自制工具来表明我们没有使用太多内存或太多处理器，但我们对有多少空间没有很好的感觉我们实际上有。 它开始使得对未来的增强进行估计变得困难。
有人对如何分析这样的系统有什么建议吗？ 我们一直没有运气好让风河工具发挥作用。
对于奖励积分：另一个复杂之处是我们的系统在不同时间有非常不同的行为； 在启动期间，它会执行很多操作，然后除了短暂的活动爆发之外，它会相对空闲。 如果有一个探查器具有某种编程方式来记录状态信息，我认为这也会非常有用。
FWIW，这是用 GCC 编译的，完全用 C 编写。
We've got a fairly large application running on VxWorks 5.5.1 that's been developed and modified for around 10 years now. We have some simple home-grown tools to show that we are not using too much memory or too much processor, but we don't have a good feel for how much headroom we actually have. It's starting to make it difficult to do estimates for future enhancements.
Does anybody have any suggestions on how to profile such a system? We've never had much luck getting the Wind River tools to work.
For bonus points: the other complication is that our system has very different behaviors at different times; during start-up it does a lot of stuff, then it sits relatively idle except for brief bursts of activity. If there is a profiler with some programmatic way to have to record state information, I think that'd be very useful too.
FWIW, this is compiled with GCC and written entirely in C.
发布评论
评论（3）
我对各种软件（包括嵌入式应用程序）进行了大量的性能调整。 我不会讨论内存分析 - 我认为这是一个不同的问题。
我只能猜测“众所周知”的想法起源于哪里，即要找到性能问题，您需要测量各个部件的性能。 这是一种自上而下的方法，类似于政府通过细分来控制预算浪费的方式。 恕我直言，它的效果不太好。
衡量可以看出你所做的事情是否产生了影响，但它很难告诉你要解决什么问题。
擅长告诉您要解决什么问题的是自下而上的方法，在这种方法中，您可以检查所支出的微观单位的代表性样本，并找出原因的完整解释 每一笔都被花掉了。 这是出于简单的统计原因。 如果有理由可以保存一定比例（例如40%）的样本，平均40%的样本就会显示出来，并且不需要大量的样本。 它确实要求您仔细检查每个样本，而不仅仅是将它们聚合成更大的样本。
作为一个历史例子，这就是哈里·杜鲁门在美国卷入二战爆发时所做的事情。 国防工业存在严重的浪费。 他刚上车，就开到工厂，采访了周围的人。 然后他回到美国参议院，解释了问题到底是什么，并解决了它们。
也许这比你想要的更多的答案。 具体来说，这是我使用的方法，以及这是一个详细的示例它。
补充：我想通过测量来发现的想法是很自然的。 82 年左右，我正在开发一个嵌入式系统，我需要进行一些性能调整。 硬件工程师提出在板上放置一个我可以读取的计时器（从他的大量资料中获得）。 IOW 他认为发现性能问题需要时机。 我感谢了他并拒绝了，因为那时我已经了解并信任随机停止技术（使用在线仿真器完成）。
I've done a lot of performance tuning of various kinds of software, including embedded applications. I won't discuss memory profiling - I think that is a different issue.
I can only guess where the "well-known" idea originated that to find performance problems you need to measure performance of various parts. That is a top-down approach, similar to the way governments try to control budget waste, by subdividing. IMHO, it doesn't work very well.
Measurement is OK for seeing if what you did made a difference, but it is poor at telling you what to fix.
What is good at telling you what to fix is a bottom-up approach, in which you examine a representative sample of microscopic units of what is being spent, and finding out the full explanation of why each one is being spent. This works for a simple statistical reason. If there is a reason why some percent (for example 40%) of samples can be saved, on average 40% of samples will show it, and it doesn't require a huge number of samples. It does require that you examine each sample carefully, and not just sort of aggregate them into bigger bunches.
As a historical example, this is what Harry Truman did at the outbreak of the U.S. involvement in WW II. There was terrific waste in the defense industry. He just got in his car, drove out to the factories, and interviewed the people standing around. Then he went back to the U.S. Senate, explained what the problems were exactly, and got them fixed.
Maybe this is more of an answer than you wanted. Specifically, this is the method I use, and this is a blow-by-blow example of it.
ADDED: I guess the idea of finding-by-measuring is simply natural. Around '82 I was working on an embedded system, and I needed to do some performance tuning. The hardware engineer offered to put a timer on the board that I could read (providing from his plenty). IOW he assumed that finding performance problems required timing. I thanked him and declined, because by that time I knew and trusted the random-halt technique (done with an in-circuit-emulator).
如果您有可用的辅助时钟，则可以使用 SPY 实用程序（可通过 config.h 文件进行配置），它可以为您提供有关哪些任务正在使用 CPU 的非常粗略的估计。
它的好处是它不需要附加到 Tornado 环境，您可以从内核 shell 中使用它。
否则，btpierre建议使用taskHookAdd过去已经成功使用过。
If you have the Auxiliary Clock available, you could use the SPY utility (configurable via the config.h file) which does give you a very rough approximation of which tasks are using the CPU.
The nice thing about it is that it does not require being attached to the Tornado environment and you can use it from the Kernel shell.
Otherwise, btpierre's suggestion of using taskHookAdd has been used successfully in the past.
我曾经在一些系统上工作过，这些系统很幸运地使用了基于 taskSwitchHookAdd 和相关函数（删除钩子等）的本地构建的监控实用程序。
“简单地”使用它来跟踪给定任务运行的滴答数。 我意识到这是用于分析的相当粗略的信息，但根据您的需要它可能很有用。
要查看每个任务使用了多少 cpu%，请计算分配给每个任务的滴答百分比。
要查看您有多少余量，请添加一个最低优先级的“空闲”任务，该任务只执行“while(1){}”，然后查看分配给它的 cpu%。 粗略地说，这就是你的净空。
I've worked on systems that have had luck using locally-built monitoring utilities based on taskSwitchHookAdd and related functions (delete hook, etc).
"Simply" use this to track the number of ticks a given task runs. I realize that this is fairly gross scale information for profiling, but it can be useful depending on your needs.
To see how much cpu% each task is using, calculate the percentage of ticks assigned to each task.
To see how much headroom you have, add a lowest priority "idle" task that just does "while(1){}", and see how much cpu% it is assigned to it. Roughly speaking, that's your headroom.