使用LLMs优化应用性能：寻找更快的等效软件库

几个月前，我在一篇博客文章中提到，应用优化的最低投入/最高回报方法是：在整个集群中部署全系统性能分析器，查看最耗能的库和进程，然后通过Google搜索寻找更快的等效替代方案。在Optimyze/Elastic，我们的全系统性能分析器客户已多次成功使用此方法。这种方法唯一的困难在于需要大量搜索替代方案，然后还要进行更多的基准测试比较搜索。

正如您可能已经想到的：我们现在有了解决方案。OpenAI和其他公司的大型语言模型（LLMs）已经在大量互联网数据上进行了训练，包括描述大量可用软件库的简介、比较它们的基准测试，以及博客、StackOverflow评论和Github内容等形式的大量相关内容。

那么，既然可以通过Google搜索相同的信息，为什么要使用LLM作为搜索接口呢？有几个原因。首先，LLM提供的功能比单纯搜索广泛得多。例如，您可以提出这样的问题：“为我找到三个替代库，列出每个库的优缺点，然后根据这些优缺点给出我应该使用哪个库的建议。“这样，我们可以将搜索软件和基准测试、解释结果以及提出建议的多步骤过程压缩为单一步骤。第二个原因是，由于LLM具有自然语言输入/输出接口，与使用Google API、抓取网页、提取信息然后生成报告相比，以编程方式解决问题并利用结果要容易得多。

如果您想尝试这个方法，几天前我开源了sysgrok（博客，代码），这是一个旨在帮助自动化系统分析和理解解决方案的工具。它组织成一系列子命令，其中一个叫做findfaster。findfaster子命令使用一个提示，询问上述问题。以下是使用它寻找libjpeg更快替代品的示例。

sysgrok还有一个”–chat"参数，在生成初始响应后，它会将您带入与LLM的聊天会话。这可用于要求澄清建议、纠正LLM犯的错误等。例如，在这里我们要求替换Python的stdlib JSON库。LLM回应了三个好的替代方案（ujson、orjson、simdjson），并建议我们使用其中最好的（orjson）。然后我们进入聊天会话，询问LLM如何安装和使用该库。

通常这种方法效果很好，并且是我遇到的这个问题的最佳自动化解决方案。也就是说，我们使用的是LLM，所以有时它会出错，甚至有些滑稽。最常见的失败方式是整体虚构软件项目。当目标的软件功能相同但性能更好的替代方案有限或没有时，很容易发生这种情况。一个很好的例子是libtiff。如果您要求findfaster为您找到libtiff的更快版本，您可能会被建议考虑TurboTiff。但TurboTiff并不是一个真实的软件项目。

如果您使用sysgrok并且它返回了一个不好的建议，我很乐意听取您的反馈，因为这些示例有助于改进提示。您可以在此处打开GitHub问题。