我有一个想法要和一些同事一起考虑。我们谁都不知道当前是否存在。
基本前提是拥有一个具有100％正常运行时间但可以动态提高效率的系统。

Here is the scenario:

   * So we hash out a system quickly to a
  specified set of interfaces, it has
  zero optimizations, yet we are
  confident that it is 100% stable
  though (dubious, but for the sake of
  this scenario please play
  along)

   * We then profile
  the original classes, and start to
  program replacements for the
  bottlenecks.

  * The original and the replacement are initiated simultaneously and
  synchronized.

  * An original is allowed to run to completion: if a replacement hasn′t
  completed it is vetoed by the system
  as a replacement for the
  original.

  * A replacement must always return the same value as the original, for a
  specified number of times, and for a
  specific range of values, before it is
  adopted as a replacement for the
  original.

  * If exception occurs after a replacement is adopted, the system
  automatically tries the same operation
  with a class which was superseded by
  it.

我们在实践中见过类似的概念吗？批评请...

Below are comments written after the initial question in regards to
  posts:

  * The system demonstrates a Darwinian approach to system evolution.

  * The original and replacement would run in parallel not in series.

  * Race-conditions are an inherent issue to multi-threaded apps and I
  acknowledge them.

解决方案

回答

在运行时运行性能基准的系统将比没有运行该系统的系统慢。如果目标是优化速度，那么一旦证明速度更快，我们为什么不独立进行基准测试并导入最快的例程呢？

我们同时启动例程的想法可能会引入比赛条件。

同样，如果目标是确保100％的正常运行时间，则我们不希望引入未经测试的例程，因为它们可能会生成无法捕获的异常。

也许想法值得作为基准测试的工具，而不是作为操作系统的工具？

回答

我在实践中见过类似的概念吗？不。但是我还是会提出一种方法。

似乎大多数目标都可以由某种可以通过CruiseControl实现的超级源控制系统来满足。

CruiseControl可以运行单元测试以确保新版本的正确性。

我们必须编写一个CruiseControl构建器插件，以针对一系列现有基准执行新版本的系统，以确保新版本得到改进。

如果CruiseControl构建循环通过，则将接受新版本。实施此过程将花费大量精力，但我认为这是可行的。单元测试和基准测试构建器必须非常漂亮。

回答

我认为像OSGi或者Spring这样的Control Container反转可以完成我们在谈论的大部分内容。 (按名称动态加载)

我们可以在他们的东西之上建立。然后实施代码以

• 将工作单元划分为离散的模块/类(策略模式)
• 通过唯一的名称标识每个模块，并将其与功能相关联
• 当请求模块时，功能会请求它，并且会随机使用具有该功能的模块之一。
• 保留性能统计信息(在执行之前和执行之后让系统打勾并存储结果)
• 如果发生异常，请将该模块标记为不使用并记录该异常。

如果模块通过消息传递来完成工作，则可以存储消息，直到操作成功完成为止；如果发生异常，请与另一个模块重做。

回答

我认为这个想法是一个有趣的理论辩论，但由于以下原因，它并不实用：

• 为确保新版本的代码正常运行，我们需要进行出色的自动测试，这是一个很难实现的目标，许多公司也未能开发出这一目标。这样的自动测试到位后，我们才可以继续实施系统。
• 该系统的全部要点是性能调整，即-代码的特定版本被替换为性能的版本。对于当今的大多数应用而言，性能至关重要。意思是，大多数应用程序的整体性能都是足够的-考虑一下，我们可能很少发现自己抱怨"此应用程序运行缓慢"，相反，我们通常会抱怨缺乏特定功能，稳定性问题，UI问题等即使我们确实抱怨速度缓慢，也通常是系统的整体速度缓慢，而不仅仅是特定的应用程序(当然也有例外)。
• 对于性能是一个大问题的应用程序或者模块，提高性能的方法通常是确定瓶颈，编写新版本并使用某种基准测试首先独立于系统进行测试。当然，也有必要对整个应用程序的新版本进行基准测试，但总的来说，我认为此过程只会发生很少的次数(遵循20％-80％的规则)。在这种情况下，与上述系统相比，"手动"执行此过程可能更容易且更具成本效益。
• 当我们添加功能，修复与性能无关的错误等时会发生什么？我们不会从系统中获得任何好处。
• 结合运行两个版本以比较它们的性能比我们想象的要多得多-不仅我们可能有竞争条件，而且如果输入的信号不是适当的基准，则我们可能会得到错误的结果(例如，如果获得了小数据包，即90％的时间是输入大数据包)。此外，这可能是不可能的(例如，如果实际代码更改了数据，则无法一起运行它们)。

听起来有用且实际上是"必须"的唯一"环境"是一个"遗传"系统，它可以自己生成代码的新版本，但这是一个完全不同的故事，并未真正广泛应用...

回答

有关高可用性系统的设计思想，请查看Erlang。

回答

我认为代码本身不会学得更好。但是，某些运行时参数可以轻松调整为最佳值，但这仅仅是常规编程，对吧？

关于即时更改，我已经分享了一个奇迹，并将其构建在Lua或者类似的动态语言之上。其中一个零件可能已经装载，如果更换了零件，请重新装载使用。在这方面也没有火箭科学。如果"旧代码"仍在运行，则完全可以，因为与DLL不同，仅在读取文件时才需要该文件，而在执行来自那里的代码时则不需要。

用处？ a ...