我们知道对象的大小取决于它的字段类型。但是对象实例化时间是否取决于其字段类型？看我的测试

也许不是一流的，对于不同的字段类型仍然给我相当稳定的结果：

这是为什么？我在笔记本（Celeron 925）上从 Eclipse 运行它，它需要 -Xmx1024M。

我有$date_string = '12/1/2014';

我需要：

1. 将其解析为时间戳号（保存在数据库中）
2. 然后解析该时间戳以以不同的格式输出，例如December 1, 2014

我假设使用DateTime 类将是首选方法（我个人觉得它非常方便）。

但是，我很好奇执行这两种解析操作的最快方法是什么。

处理需要从数据库传输大量数据的应用程序。它包括 SELECT 和 UPDATE 查询（即读取和写入数据库）。

首先，我需要获取所有产品的列表（大约 1000 个 SKU）。SELECT 查询非常简单：

然后对每个产品进行一些自动更新。UPDATE 查询是这样的：

现在的问题是哪一个会更快/更好地执行：一次操作所有记录的单个查询，还是单独处理每个产品的 PHP 循环（例如foreachor while）（1000 个单行查询）？后者当然需要WHERE model = 'ABC'and LIMIT 1。

为了使问题更复杂（和全面），请考虑其他影响标准，例如：

• 如果目标行数不同：100 或 100,000 行会怎样？
• 如果涉及多张桌子怎么办？请参阅下面的 JOINed 查询示例。

.

是否有一般的“经验法则”来决定在这种或那种情况下哪种方式更好？

我正在阅读MHZ - lmbench 的创建者的 Benchmark 论文剖析，并在旁边浏览代码。

1. 论文可以在@MHz 下载：Microbenchmark 的剖析
2. 源代码lmbench-3.0由 Carl Staelin 和 Larry McVoy 编写

在 BENCH_INNER() 宏里面我有一个疑问：

1. 据我了解， BENCH_INNER 用于自动计算所选时间间隔（“足够”）的最佳迭代次数。循环一直执行，直到我们不断迭代一段代码“loop_body”，这将占用我们选择的时间间隔的至少 95%，范围从 5 毫秒到 1 秒。

2. 为简单起见，让我们将“足够”设为 10000 微秒

3. 我们从 __iterations = 1 开始
4. 假设随着时间的推移，我们达到了 __result > 1.2 * '足够' 的阶段，即 __result > 12000 微秒
5. 现在由于 __result > 150 微秒，我们继续并缩放 __iterations 的值，以便 __result 大约等于 1.1 * '足够'
6. 但在我们重新计算 __result 之前，我们将打破循环，因为之前的 __result > .95 * '足够了'
7. 我们继续保存 __result 的值和修改后的 __iterations 值（这里 __result 的值不是我们保存的 __iterations 的值）

这种情况下的代码不应该重新计算 __result 吗？我错过了一些基本的东西吗？

可能重复：
Java 异常有多慢？

以下两个程序的运行时间大致相同：

但是接下来的两个程序所花费的时间是相对不同的：

我想一个简单的 try/throw/catch 机制看起来有点像一个至少部分尾调用优化的返回（所以它直接知道控制应该返回到哪里（最近的捕获）），但是，当然，JRE 实现做了很多优化。

为什么后者差别很大，而前者差别不大？是因为控制流分析确定前两个程序几乎相同，而实际的 try/throw/catch 特别慢，还是因为 Return 的find展开到某种程度，从而避免了方法调用，而 Throw 的却不能， 或者 ..？谢谢。

编辑：这个问题对我来说似乎与Java 异常有多慢？因为它没有问为什么在与此类似的情况下会有如此大的差异。它还忽略了创建异常对象所花费的时间这一事实（除非fillInStackTrace被覆盖，否则包括遍历堆栈并为其创建数组）。然而，它显然回答了我的部分问题：“是不是因为控制流分析确定前两个程序几乎相同”——尽管在答案中提到堆栈跟踪似乎很奇怪（这可能会使任何实际的 throw/catch 操作相形见绌——除非它进行一些复杂的分析来确定堆栈从未见过，这会使@Stephen 的回答变得奇怪）。

为什么缓冲 0.030000 秒与“更好”缓冲 0.030000 秒相同？如果 4 倍大的 linesize 不会改变时间，我怎样才能加快速度呢？

测试

代码

对于ELKI，我需要（并且拥有）比标准 Java JDK 和 Collections API 提供的更灵活的排序实现。（排序不是我的最终目标。我使用部分排序来批量加载索引结构，例如 kd-tree 和 R*-tree，并且我想为这些提供一个相当通用的实现，比目前 ELKI 中的更通用- 但无论哪种方式，优化排序都意味着优化索引构建时间）。

但是，排序算法的缩放比例会因您的数据大小而异。对于微小的数组，插入排序可以很好地执行是一个众所周知的事实（事实上，大多数快速排序实现将回退到低于某个阈值的插入排序）；不是通过理论，而是通过排序理论未考虑的 CPU 流水线和代码大小影响。

所以我目前正在对一些排序实现进行基准测试，以找到满足我特定需求的最佳组合；我希望我更灵活的实现在某种程度上与 JDK 默认实现（已经微调，但可能适用于不同的 JDK 版本）相提并论。

从长远来看，我需要这些东西易于重现和重新运行。在某个时候，我们会看到 JDK8。在 Dalvik VM 上，结果也可能与 Java 7 不同。哎呀，它们甚至在 AMD、Core i7 和 Atom CPU 上也可能不同。所以也许 Cervidae 会包含不同的排序策略，并在类加载时间上选择最合适的一种。

我目前的工作在 GitHub 上：https ://github.com/kno10/cervidae

所以现在到实际的问题。最新的 caliper 提交为宏基准添加了一些实验性代码。但是，我面临的问题是我需要两者。当运行时间小于定时器分辨率的 0.1% 时，Caliper 宏基准测试失败；对于 10000 个对象，一些算法达到了这个阈值。与此同时，微基准测试抱怨说，当你的运行时间太长时，你应该做一个宏基准测试……

因此，为了对不同的排序大小进行基准测试，我实际上需要一种根据运行时动态地从微基准测试切换到宏基准测试的方法。事实上，我什至更喜欢 caliper 自动意识到运行时对于宏基准测试来说足够大，然后只进行一次迭代。

现在，我正在尝试通过使用以下方法来模拟它：

在两种情况下共享基准测试代码。另一种代码是使用

两个“适配器”中哪一个更可取？从微观一直到宏观获得一致基准测试的任何其他提示？

鉴于 caliper WebUI 目前无法使用，您使用什么来分析结果？我目前正在使用一个小型 python 脚本来处理 JSON 结果并报告加权平均值。事实上，我更喜欢旧的文本报告而不是 Web UI。

哦，当热点编译发生在基准测试循环中时，有没有办法让 Caliper 重新运行基准测试？现在它记录了一个错误，但也许它可以重新启动基准测试的那部分？

我一直在对以下代码进行微基准测试，我注意到一些有趣的东西，我希望有人能对此有所了解。这导致了一种情况，看起来 for 循环可以继续快速运行，同时阻塞 JVM 中的其他线程。如果这是真的，那么我想了解为什么，如果不是真的，那么任何对我可能遗漏的东西的见解都会受到赞赏。

为了建立这种情况，让我带您了解我正在运行的基准测试及其结果。

代码非常简单，遍历数组中的每个元素，对其内容求和。重复“targetCount”次。

在我的 4 核 - 2Ghz Intel Sandy Bridged/i7 笔记本电脑上，在 OSX 上运行 Java 6 (Oracle JVM)。此代码反复运行到

2.626852686364034 非竞争字节数组读取/ns [totalTestRun=3806.837ms]

（我已经剔除了用于加热 JVM 的重复运行）

这个结果在我看来是合理的。

当我开始测量 JVM Jitter 时，这很有趣。为此，我启动了一个休眠 1ms 的后台守护线程，然后计算出它真正休眠的时间比 1ms 长了多少。我更改了报告以打印出每次重复测试运行的最大抖动。

2.6109858273078306 非竞争字节数组读取/ns [maxJitter=0.411ms totalTestRun=3829.971ms]

为了了解我的环境的“正常”抖动，在开始实际测试运行之前，我在没有任何工作的情况下监控抖动，并且以下读数是典型的（均以毫秒为单位）。因此，0.411ms 的抖动是正常的，并不那么有趣。

我在这个问题的结尾包含了我如何测量抖动的代码。

然而有趣的部分，是的，它确实发生在“JVM预热”期间，因此不“正常”，但我想更详细地了解以下内容：

请注意，抖动超过 2.5 秒。通常我会把它归结为GC。但是，我确实在测试运行之前触发了 System.gc()，并且 -XX:+PrintGCDetails 此时没有显示 GC。事实上，在任何测试运行期间都没有 GC，因为在这个总结预分配字节的测试中几乎没有发生对象分配。每次我运行新测试时也会发生这种情况，因此我不怀疑它是来自其他随机发生的进程的干扰。

我的好奇心猛增，因为当我注意到总运行时间的抖动非常高时，实际上每纳秒读取数组元素的数量或多或少保持不变。因此，在这种情况下，一个线程在 4 核机器上严重滞后，而工作线程本身并没有滞后，也没有 GC 进行。

进一步调查，我查看了 Hotspot 编译器在做什么，并通过 -XX:+PrintCompilation 找到以下内容：

打印出来的这两行之间的延迟约为 2.5 秒。就在包含大 for 循环的方法已将其优化代码标记为不再进入时。

我的理解是 Hotspot 在后台线程上运行，当它准备好换入新版本的代码时，它会等待已经运行的代码到达安全点，然后再换入。如果是一个大的 for 循环，位于每个循环体的末尾（可能已经展开了一些）。我预计不会有 2.5 秒的延迟，除非此换出必须在 JVM 中执行停止世界事件。在去优化以前编译的代码时会这样做吗？

所以我对 JVM 内部专家的第一个问题是，我是否走在正确的轨道上？2.5 秒的延迟是否是由于将该方法标记为“未进入”？如果是这样，为什么它会对其他线程产生如此极端的影响？如果这不太可能是原因，那么任何关于其他调查内容的想法都会很棒。

（为了完整起见，这里是我用来测量抖动的代码）

问题

可以说我有这个功能：

我想调用它并能够检查它使用的最大内存量。

换句话说：memory_get_function_peak_usage($callback);. 这可能吗？

我试过的

我使用以下值作为我的非单调递增$i参数hog()：

本质上是：

附上memory_get_usage()

输出：

如果我存储 的返回值hog()，结果开始看起来更真实：

输出：

正如预期的那样，现在它向我显示了返回的内存量，但我需要使用的总内存。

使用register_tick_function()：

我不知道，但事实证明，当你这样做时：

它不会为函数内的每一行、语句或代码块打勾hog()，只针对declare块内的代码 - 所以，除非函数在其中定义，否则这个选项是不行的。

与gc_*功能混合：

我尝试使用 , 的组合（我必须说希望不大）gc_disable()，gc_enable()并gc_collect_cycles()通过上面的两个实验来查看是否有任何改变 - 它没有。

使用以下 Groovy 代码片段，我得到了一些意想不到的基准测试结果：

不得不说，我使用了编译好的类文件，并通过 Reflection API 调用了它。长话短说（不要问;）。对于第一印象，我使用了 10 轮 + 5 次热身和 10000 次循环。（junit-benchmark 框架）我的 JDK 是 Verison 1.7.0_09，我使用的是 Groovy 2.1。我在有和没有调用动态支持的情况下编译了代码 2 次。关键是，带有 invokedynamic 的基准测试比正常编译的基准花费的时间要长得多。我还用斐波那契数做了其他基准测试，其表现与预期的一样（indy 花了大约一半的时间）。

有人知道这里出了什么问题吗？

谢谢。