JobCache是CloudBees Accelerator的一个内置特性，它智能地分析过去的编译任务和最近的更改，然后智能地重用不受任何最近更改影响的对象文件。这可以使用相同的构建硬件将CloudBees加速器的构建时间减少40%。此外，JobCache可以减少资本支出（CapEx）和运营支出（OpEx），同时以更少的速度保持相同的构建速度机器。怎么它的workjobcache允许构建避免重新编译以前构建的对象文件（如果它们的输入没有更改）。即使在清理构建输出树之后，JobCache仍然可以工作（例如，通过使用"makeclean"）。通过缓存和重用对象文件，JobCache可以显著加快完全builds.JobCache使用缓存"slots"。启用JobCache时，eMake（CloudBees Accelerator的make版本）为命令行选项、相关环境变量分配和当前工作目录的每个组合维护一个插槽。槽可以是空的，也可以保存以前缓存的结果。如果适当的槽位保存了最新结果，则会发生缓存"命中"并避免编译。如果eMake检测到可能导致不同结果的文件系统更改（使用相同的命令行选项、环境变量分配和当前工作目录），则缓存的结果将过时。这样的文件系统更改包括编译期间读取的任何文件，这意味着eMake中包含所有源文件、GCC预编译头和编译工具根。怎么了不同的是，Cloudbees加速器JobCache比Android版本的ccache快20%到50%。在下面的图表中，使用24个处理核心，CloudBees Accelerator with JobCache（eMake w/JobCache）所用时间不到gmake在64位时使用ccache的一半核心。那个基准测试使用androidm，gmake使用64核和ccache，CloudBees加速器使用24个内核核心.JobCache其设计具有可靠性，甚至可以使用用于生产构建。ccache已经知道了一些缺点，这些缺点可能会导致它产生假阳性，从而使其在生产中使用有风险builds.JobCache更灵活。ccache只在gcc生成.o文件时工作。但是，作为编译的副作用，gcc可以生成其他文件，比如分析数据和调试符号。ccache通常只在启用这些特性时拒绝缓存编译。即使启用了这些功能而其他文件已启用，JobCache也将缓存生成的.CloudBeesAccelerator和JobCache还可以通过丰富的可视化用户界面更容易地识别构建瓶颈并进一步加速构建—这使得性能和缓存未命中分析变得微不足道。当ccache中发生缓存未命中时，几乎不可能确定为什么是JobCache此外，它的共享JobCache功能更具协作性，允许多个用户共享缓存的内容，从而消除了在整个团队中重建未更改模块的成本和冗余工作。共享JobCache不仅仅为单个开发人员将对象文件存储在本地缓存中，而是为了每个人的利益将它们存储在共享缓存中。现在，多个开发人员可以通过以只读模式同时访问公共（共享）缓存来重用黄金构建的生成输出，从而提高效率并提高总体质量。现在每个人都可以使用最新版本的模块。Ccache只有基本的共享能力，没有质量保证。更快建造或更少的硬件？对于许多用户来说，构建加速是一个关键目标。使用CloudBees加速器，用户可以通过将更多的计算资源放入构建场和/或使用JobCache。不过，对于一些用户来说，从资本支出成本的角度来看，投入更多的硬件来解决这个问题是不可行的。对于其他人来说，降低维护大型服务器场的运营成本（如房地产、冷却、电力）可能是一个商业目标。在这种情况下，JobCache还可以通过允许使用较少的计算资源来保持构建速度，这也是有价值的。在下面的示例中，使用JobCache的16核上的构建比不使用的64核上的构建快JobCache。关于CloudBees Accelerator CloudBees Accelerator是一个构建和测试加速平台，适用于基于make的Android AOSP、嵌入式Linux、BitBake，以及visualstudio构建环境，它智能地、自动地跨物理或云cpu集群并行化软件任务，从而大大缩短构建和测试周期时间。试试它是免费的