最近一直很纠结，发现人真的不能认真。

做个核心算法库的原型。既然是原型，实际每个算法，实际存储空间，以功能实现为原则，做就可以了。

但该死的理论和工程没有实际的联系关系。例如一个信息流，我们是按照byte为单位存放，还是按照bitstream方式存放，这两种存放，对后期算法会有很大的影响。前者倒也方便，后者要多出一堆解压操作。如果对这些信息流进行诸如排序，重置位等算法操作，差异更是巨大。

曾经给自己定了四个字“一切从简”。别想复杂咯。怎么简单怎么来。

但“一切从简”也不是绝对的。如果一个架构设计，特别是底层数据结构的设计变动过大，对后期的代码的优化或工程化的工作量的影响是非常大的。

所以从未找到评价函数的纠结，到“一切从简”的纠结，又到了“一切从简”的判断标准的纠结。

经历了3个星期，总算折腾完基础创建，打印，和基础操作的代码。在更上一层代码时，出现了一个问题。

要么增加辅助数据结构，以便于上一层算法的有效设计。要么修改底层数据结构。对于后者，等于将前面3个星期的推导重来。留下的无非是函数接口，和一些列的宏定义。还好可以分函数，可以宏嵌套，否则改起来等于完全重写。

2天时间，几乎啥事没干，除了喷水，就在考虑，验证辅助数据结构存在的必要性，以及合并成原先基础数据结构后，对算法的影响。数据结构中，没有冗余或冗余量很小，信息关联性强，则会导致计算复杂度提高。这个道理很简单。

双向链表自然必单向链表好操作的多。

曾经纠结的地方在于，其实我完全可以用一个最简单的数据结构描述底层，随后，上层系统可以进行构件，并将算法依次写出，验证完毕，原型OK。我们把这种函数调函数实现复杂算法的逻辑，可以抽象成一个立体网络。

也可以简单的看作，一个C文件，被另几个C文件的函数调用，则这个C文件在空间中处于下方，而C文件中间相互未调用的函数属于同一个平面。

如果一个底层数据结构的变动，会导致整个立体网络中的大部分结点（实际就是算法函数）产生差异，则这个原型OK等于不OK。

目前的态度是，如果我能将两者可选择的数据结构，或者一个未证明过，可能更优（存储空间利用率）的数据结构，确认其替换上系统，对上述立体网络的影响能局限在一个较底层的范围，那么这个可能更优的方案就暂时放放。

所以还是别太较真的好。如果存储空间利用率不够，以后再根据实际应用情况考虑空间优先还是算法优先。算法可能更简单，但是更复杂的数据结构带来的辅助算法的复杂性，导致系统计算性能的下降，可能超过空间利用率不够，带来的数据搬运的额外耗费时间，所导致的计算性能的下降。

其实，以前一致坚持一个原则，系统硬件资源使用率85%为限。如果超过，则不再优化。经验之谈。

现在，我认为，系统架构，和数据结构也应该遵循糊涂标准，局部最优的方案尽可能的原理，局部性能达到80%的线足够。

这里有个悖论，局部方案最优，意味着局部的关联性越强，一旦堆成整个系统，不同局部资源相互冲突，倾辄，最后整体系统不是这里出瓶颈就是那里有死锁。

宽宽松松的心态，邋里邋遢的做人，有点余量的系统，才是大成。。。。

系统设计，放不下的，不是问题，是自己的态度。哈。