问题标签 [tradeoff]

我是一名 C/C++ 开发人员，这里有几个问题一直困扰着我。

• “常规”代码和内联代码之间有很大区别吗？
• 主要区别是什么？
• 内联代码只是宏的“形式”吗？
• 选择内联代码时必须做什么样的权衡？

谢谢

在设计任何桌面应用程序时，是否有关于应用程序应使用多少内存的一般规则？

对于重量级应用程序，这些应用程序可以很容易理解或至少对其进行分析，例如 Firefox 或 Google Chrome。但是对于较小的实用程序或业务线应用程序，可接受的内存使用量是多少？

我问是因为我最近遇到了内存使用和性能之间的权衡，想知道是否对此有任何普遍共识？

编辑：平台是 Windows XP，适用于机器只能运行富 Internet 应用程序的用户。

我的具体权衡问题是在内存中缓存大量图像。如果可能的话，我希望我的应用程序缓存尽可能多的用户内存允许。我已经这样做了，以便应用程序将缓存到某个最大限制，考虑到目前的内存压力。.

但是什么是一个好的数字？你怎么想出一个？这就是我要问的重点。

使用 System V 和 Posix 信号量之间的权衡是什么？

我经常从测试驱动开发人员那里听到，让一个函数隐含地获取大量信息是一件坏事。我可以看到从测试的角度来看这会很糟糕，但从封装的角度来看有时不是必要的吗？想到以下问题：

使用 Random 和 OrderBy 是否是一个好的 shuffle 算法？

基本上，有人想在 C# 中创建一个函数来随机打乱数组。有几个人告诉他，随机数生成器应该作为参数传入。对我来说，这似乎是对封装的严重违反，即使它确实使测试更容易。数组混洗算法是否需要任何状态，而不是它正在混洗调用者不必关心的实现细节的数组？获取此信息的正确位置难道不是隐式的，可能来自线程本地单例吗？

我想知道使用数据库的权衡以及其他选择是什么？另外，哪些问题不适合数据库？

我关心关系数据库。

这是一个关于权衡的问题。

想象一个社交网络。每个用户都有一条状态消息，他可以随时更改。每当他改变它时，他所有的朋友都会通过一堵墙得到通知（比如在 Facebook 中）。

使这项工作。我们有 3 个表 Users(id, name), FriendLists(userId,friendUserId), Notifications(?)。

现在让我们假设每个用户在他的朋友列表中大约有 50 个朋友。我面临着两难境地——如何实现通知表。

第一个选项

发送通知：

在这种情况下，对于每个状态更改，我们创建 50 条记录（假设有 50 个朋友）。这是不好的。然而，好的一点是检索特定用户的通知非常快，因为我们在 toUserId 上有一个聚集索引。

第二个选项

发送通知：

在这里，我们每次状态更新只插入一条记录。这很好。不好的一点是通知的检索会变慢，因为记录不是由 toUserId 聚集的。

两种方法获取通知是相同的：

那么您对此有何看法？

问题：在未加权的无向图中找到最短路径。

广度优先搜索可以找到两个节点之间的最短路径，但这可能需要 O(|V| + |E|) 时间。预先计算的查找表将允许在 O(1) 时间内回答请求，但代价是 O(|V|^2) 空间。

我想知道的是：是否有一种算法可以提供更细粒度的时空权衡？换句话说，是否有一种算法：

1. 在比 O(1) 更多的时间内找到最短路径，但比双向广度优先搜索更快
2. 使用比 O(|V|^2) 占用更少空间的预计算数据？

在实际方面：该图有 800,000 个节点，被认为是一个小世界网络。全对最短路径表的数量级为千兆字节——这在当今并不离谱，但它不符合我们的要求。

但是，出于好奇，我问我的问题。让我彻夜难眠的不是“我怎样才能减少所有对查找表的缓存未命中？”，而是“那里有我从未听说过的完全不同的算法吗？”

答案可能是否定的，没关系。

我试图了解在 Cocos2d 中使用 CCUIViewWrapper 与移植功能的优缺点。例如，在 CCUIViewWrapper 中使用 UITableView 会更好，还是使用 CCTableViewSuite。乍一看，我认为包装器是更好的方法，因为大概它允许我做 UITableView 提供的所有事情，但是我缺少关键细节吗？包装器是否存在严重的限制，无论是实际使用苹果 sdk 对象还是无法利用 Cocos2d 中带有像 CCTableView 这样的移植对象的某些功能？

首先，我不是在寻找一种方法来强制编译器内联每个函数的实现。

为了减少错误答案的水平，请确保您了解inline关键字的实际含义。这是很好的描述，inline vs static vs extern。

所以我的问题是，为什么不标记每个函数定义inline？即理想情况下，唯一的编译单元是main.cpp. 或者对于无法在头文件中定义的函数（pimpl idiom 等）可能还有更多。

这个奇怪请求背后的理论是它会给优化器提供最大的信息来处理。它当然可以内联函数实现，但它也可以进行“跨模块”优化，因为只有一个模块。还有其他优点吗？

有没有人用真实的应用程序试过这个？性能提高了吗？减少？！？

标记所有函数定义的缺点是什么inline？

• 编译可能会更慢并且会消耗更多的内存。
• 迭代构建被破坏，每次更改后都需要重新构建整个应用程序。
• 链接时间可能是天文数字

所有这些缺点只会影响开发人员。运行时的缺点是什么？

使用动态解析器​​的空间相关优势是否超过了预先生成的查找表的时间相关优势？

长版：

我正在编写一个化学参考工具，并包含一个功能，可以自动命名符合特定模式的公式；例如C[n]H[2n+2] => [n]ane；其中[n]是 LHS 的整数；以及 RHS 上名称数组的索引。( meth, eth, …)

据我所知，这可以通过以下两种方式之一实现：

1. 我预先生成了一个键/值对偶查找字典formula <=> name；应用程序启动时（启动速度较慢），或与应用程序一起发布的静态列表（下载速度较慢）。

2. 公式由定制的解析器动态评估。

在方法 1 中，名称 => 公式查找变得简单了一个数量级；但是生成器将，除非我想用应用程序传送几十兆字节的数据，否则必须有一个预设的、相当低的n.

更复杂的是公式可以有多个术语。如C[n]H[2n+1]OC[n']H[2n'+1]; 对于这些中的每一个，可能匹配的数量随着 几何增加n。此外，使用这种方法会像没人管一样吃掉 RAM。

方法 2.让我支持使用相当小的查找表的相当大的值n，但使名称 => 公式查找更加复杂。与与应用程序一起交付的预生成文件相比，它还可以让我纠正生成逻辑中的错误，而无需交付新的数据文件。

这还要求将每个公式与几个规则的粗略测试进行匹配，以确定它是否适合；如果有很多规则，这会花费一些时间，这可能会导致界面明显变慢。

那么问题来了：

1. 在我没有考虑的权衡中是否有任何考虑因素，或者我没有考虑过的方法？

2. 使用动态解析器​​的好处是否证明了增加的实现复杂性？