WaitForTargetFPS
情况一：
是关于帧数限制的,你可能开了垂直同步，防止撕裂。
在显示器的帧缓存会被不同步的显卡的帧缓存给替换掉，导致显示器显示到一半的时候，内存被换掉，你看到上频是上一针的画面，下频是下一针的画面，游戏刷新的频率越快，撕裂就越严重， 所以就会撕裂了。
开了垂直同步,是指将游戏帧数锁定到和你的显示器刷新频率一样的，因为显卡和显示器的刷新频率不一样。简单的说， WaitForTargetFPS消耗越高，说明被压缩的帧数越多，能用的资源越多，等待的可用的进程越多。只要关闭垂直同步就可以了。
比如说你项目能跑到60帧，但是你限定最高是30帧，那么他就会强制压到30帧，这中间可能会出现差值，所以需要等待。
情况二：
该参数一般出现在CPU开销过低，且通过设定了目标帧率的情况下（Application.targetFrameRate）。当上一帧低于目标帧率时，将会在本帧产生一个WaitForTargetFPS的空闲等待耗时，以维持目标帧率。
解析：该项在Unity引擎的主循环中其实是最早执行的，即引擎实际上是根据上一帧的CPU耗时，在当前帧中通过增补WaitForTargetFPS的方式来将运行FPS维持到目标值。比如，目标帧率为30帧/秒，上一帧耗时15ms，那么当前帧中WaitForTargetFPS将会是18（33-15）ms，但是这一帧中其他耗时为28ms，那么在Profiler中这一帧的总耗时就变成了46（18+28）ms。
因此，由该值造成了Profiler开销较高的现象，其实是耗时的“假象”，在优化过程中，你对它可以“视而不见”。
Editorloop
这个参数跟编辑器运行相关，当编辑器存在消耗比较大的运行时，这个值就会跑得非常高。
有的时候在使用某些插件的时候，因为会存在编辑器扩展，也会具有比较大的消耗，这个时候需要点击Layout→Revert Factory Settings重置。
用 while 写一个无限循环的脚本会不停占用 CPU，直到 100%。原因：
一个空的死循环不会做任何事情，但是会不断向 CPU 申请时间片，直到把每一片时间都占用完。
这样 CPU 就没有空余的时间片来做其他有用的事情了。
The CPU cannot do anything else while it's executing that loop (which never ends).
Even if you're using a pre-emptive multi-tasking system
(so that infinite loop will only clog forever its own process or thread),
the loop will "eat" its time slice each time
the OS's pre-emptive scheduler hands it the CPU for the next slice -- doing nothing,
but eating up one slice's worth of CPU time each and every time,
so that much CPU is lost to all other threads which could otherwise be doing useful work.
待续。。。