什么是你见过的最荒谬的悲观化？

 

我们都知道过早优化是万恶之源，因为它会导致无法读取/不可维护的代码。 更糟糕的是，当某人实施“优化”时，他们认为这会更快，但最终会变得更慢，并且变得越来越不可靠，等等。更糟的是，你看过的最荒谬的例子是？

在一个旧项目中，我们继承了一些拥有巨大Z-8000体验的嵌入式系统程序员。

我们的新环境是32位Sparc Solaris。

其中一个人去了并且把所有的整数都换成了短裤来加速我们的代码，因为从RAM中获取16位比获取32位更快。

我不得不写一个演示程序来表明在32位系统上抓取32位值比抓取16位值更快，并解释为了获取16位值，CPU必须使32位宽内存访问，然后屏蔽掉或移动16位值不需要的位。

我认为“过早优化是万恶之源”这句话是用过的方式。 对于许多项目而言，它已成为一个借口，直到项目后期才考虑绩效。

这句话常常是人们避免工作的拐杖。 当人们真正说“哎呀，我们真的没有想到这一点，现在没有时间处理它”时，我会看到这句话。

我见过很多更愚蠢的表现问题的“荒谬”例子，而不是由于“悲观化”

  • 在程序启动期间读取相同的注册表密钥数千次（或10万次）。
  • 加载相同的DLL数百或数千次
  • 通过不必要地保留文件的完整路径来浪费兆字节的内存
  • 不组织数据结构，以便占用比他们所需更多的内存
  • 调整存储文件名或路径到MAX_PATH的所有字符串
  • 对发生事件，回调或其他通知机制的事物进行免费投票

    • 我认为更好的表述是：“没有衡量和理解的优化根本不是最优化 - 它只是随机变化”。

    良好的性能工作非常耗时 - 通常更多的是功能或组件本身的开发。

    数据库是悲观的乐园。

    收藏夹包括：

  • 将表格分成多个（按日期范围，字母范围等），因为它“太大”。
  • 为退役的记录创建一个归档表，但继续将其与生产表联合。
  • 通过（部门/客户/产品等）复制整个数据库
  • 拒绝将列添加到索引，因为它太大。
  • 创建大量汇总表是因为从原始数据重新计算得太慢。
  • 创建包含子字段的列以节省空间。
  • 非规范化为字段即数组。

    • 这是我的头顶。

    链接地址: http://www.djcxy.com/p/86743.html

    上一篇: What is the most ridiculous pessimization you've seen?

    下一篇: C array arithmetic and pointers