至从有了调试工具，我们编程对调试工具的依赖无比巨大
调试工具的断点功能又是使用最为平凡，也是最核心的功能。辅助的还有打印、写日志、日志线程等。
可是用着用着，发现，断点，漂浮框加多了，附加或者调试运行时越来越卡，所以用一段时间之后，常常选择删除所有断点以及调试信息，从头开始。此时会发现工程运行飞一样的爽。
然而，今天发生一件事，却让我对断点功能认知有了更深入的了解：
首先，断点的确会影响工程运行的效率。这点从一些资料上得到证实：
“操作系统提供了一些寄存器，里面存了调试断点的位置，这样操作系统在每执行一条命令（或者一组原子命令）以后就查看一下是否到了断点的地方，再确定是跳转到调试程序还是继续执行。于是我们上网查了一下，果然被我猜中了，原来Intel 的80x86 CPU提供了几个寄存器用于软件调试，他们是：Dr0 … Dr7，其中Dr4和Dr5保留不用，只能用6个。这样看来，既然硬件提供了对应寄存器，他们一定也会对此进行一些硬件上的优化，使得每次判断是否跳转这个过程尽可能的快，避免对性能造成的损失。”
其次，断点是可以加判断条件或者操作的，如此一来查询到寄存器之后，程序继续执行其它操，将大占用线程时间片。
甚至使一些线程，如渲染线程，在一个执行同期内无法完成必要的工作，至使程序无法运行。今天调试引擎时，在调查渲染线程中一个变量值的变化时，加了一个断点，并在断点中加了判断条件，使他在值异常时能命中断点。然而结果却很意外。引擎加载场景后跟本无法正常工作，勉强能加载极小的场景，一脸懵逼呀。大场景中引擎代码运行看上去很正常，然而却无法响应外部操作。
起先，以为加进去的打印信息以及断点等调试信息过多，影响了引擎运行，于是删除所有调试信息并重新编译注册。然而并没有什么用，每次一运行就出现相同的问题。
最后，偶然间，停止调试时，画面定格在一个加了条件的断点上，晃然间，醍醐灌顶。一定是每次运行前加的一个断点影响到了。果然，去掉断点后，便正常了！！！
最后，近一估时间，写日志和加调试代码才是最终极的武器。断点，只能应付一些最普通的小事故。
目前的阶段是不舒服的，那你应该是在成长，愿你以后都会主动走出舒适区，不断成长，迎接你想要的享乐时光！