考虑到问题的一个简单实现,我正在寻找一种更快的方法来找到Python列表中最常见的单词.作为Python访谈的一部分,我收到的反馈是,这种实现效率很低,基本上都是失败的.后来,我尝试了很多我发现的算法,只有一些基于堆栈的解决方案速度稍微快一些,但不是绝大多数(当缩放到数千万个项目时,heapsearch的速度提高了大约30%;在千万倍的长度上,它几乎是相同;使用timeit).
def stupid(words):
freqs = {}
for w in words:
freqs[w] = freqs.get(w, 0) + 1
return max(freqs, key=freqs.get)
由于这是一个简单的问题而且我有一些经验(虽然我无处算法大师或竞争编码器)我很惊讶.
当然,我想提高我的技能并学习解决问题的更好方法,所以你的意见将得到赞赏.
澄清重复状态:我的观点是找出实际上是否有更多(渐近)更好的解决方案,其他类似的问题已经选择了一个不太好的答案.如果这还不足以使问题变得独一无二,那么当然要关闭这个问题.
更新
谢谢大家的意见.关于访谈情况,我仍然认为手写搜索算法是预期的(可能更有效)和/或审阅者从另一种语言的角度评估代码,具有不同的常数因素.当然,每个人都可以拥有自己的标准.
对我来说重要的是验证我是否完全无能为力(我的印象是我不是)或者通常只写不是最好的代码.仍然有可能存在更好的算法,但如果它在这里为社区隐藏了几天,我就可以了.
我正在选择最受欢迎的答案 - 这样做似乎是公平的,尽管不止一个人提供有用的反馈意见.
次要更新
看起来使用defaultdict比使用'get'方法有明显的优势,即使它是静态别名的.
我正在设计一个 REST API，最近我考虑了如何为动态内容进行大部分缓存（在我对这个主题的响应之后），同时尊重 HTTP（以及 REST）的原则。
显然，规范的解决方案（至少在我的理解中）是使用 etags，但这不会以任何方式减少请求的数量，只会减少大小。
我正在考虑在 URL 中嵌入一个版本（它将是服务器生成的，基于实际内容 - 无论是序列号还是一些哈希）。我将解释该方案和用户场景以及我认为它将如何提供帮助，然后提出我的问题。
设置
GET /entity/{id}/
返回临时重定向到/entity/{id}/{current_version}无缓存标头。
GET /entity/{latest_version}/
永远返回带有缓存的 OK 响应。
GET /entity/{old_version}/
返回 410 Gone（我实际上不想保留旧版本）。
GET /entity/?[查询]
是一些搜索，返回到当前版本的结果实体的链接列表。没有缓存。
使用场景以及我认为它会如何帮助
用户应用程序 (AJAX) 总是以某种查询开始，然后它必须提取实体的描述。由于预计单个客户端结果集的更改不会非常动态，因此使用上述方案似乎是个好主意，客户端每次都从查询中提取新结果，但如果大多数实体自上次访问以来没有更改，它们将已经缓存在浏览器中。如果这个假设是真的，这将导致请求数量和总大小显着减少。
使用 etags 会导致更简单的 URI 方案，但可能更复杂和繁重的服务器端实现。
笔记和问题
1
我知道有人会建议/entity/{id}/应该是一个返回列表版本的集合，但版本实际上并没有被存储、有用或需要。它更像是最新版本的同义词。我的问题是，除了一般原则之外，是否有人认为这有任何问题。这是受保护的 API，在这种情况下我不关心 SEO，它对客户端是透明的。实际上，由于 API 或多或少会超链接，因此通常不会实际直接调用 /entity/{id}/ ，而是使用返回的任何结果。例如，它可以用于上下文无关链接。
2 我对旧版本的 410 Gone 有一些疑问。一方面，此版本不再可用，无论如何客户都不应该访问它。另一方面，如果客户端毕竟要求它（无论出于何种原因），将永久重定向返回到 /entity/{id}/ 可能是有意义的（可能比临时重定向到当前版本更好）。
3 说到重定向。301 被固定用于永久重定向，但 302 是临时的最佳选择吗？最重要的是浏览器支持（它将是 AJAX）。
4 当然，主要问题是使用 URLs 而不是 etags 进行缓存（希望浏览器缓存）。如果有人在高负载下（相对于服务器功能，咳）有实际经验，我将很感激分享。
补充说明
经过更多研究，版本化资源存在问题，它是链接资源更新的传播。有两种选择：
链接资源的特定版本。这意味着服务器端逻辑将是繁重和繁琐的，因为更新必须通过反向链接传播给链接资源；
链接 /latest/ 版本。这意味着即使资源和链接资源的具体版本都在本地缓存，客户端（浏览器）也必须向 …