翻译自：https://perfetto.dev/docs/case-studies/memory#heapprofd
想看一下项目在真机上的表现，所以工作之余用了Perfetto来做项目的性能测试。阅读官方文档的时候发现了这一章节介绍了Linux内存管理的一些基础概念，所以就简单翻译了一下。
从内核的角度，内存被划分为等大小4KiB的块，这些块被称为页（pages）。
这些页被组织于连续的虚拟空间中，此空间称为VMA（Virtual Memory Area）。
当一个进程通过 mmap()
系统调用请求内存时，VMA就会被创建。一般情况下，应用不会直接调用mmap()，而是通过内存分配器间接调用，像是
C 的 malloc(), C++ 的 operator new() 或是 Java
的 new X() 等等。
VMA可以被分为两种类型：文件后备页（file-backed）与匿名页（anonymous）。
预处理：构建加速网格
找一个包围盒，在包围盒中构建均匀网格，记录每一个与物体相交的网格
光线与场景求交
射出一道光线，让光线与格子求交，若格子内存在物体，再让光线与物体求交：光线与格子求交是快速的，而与实际物体求交是很慢的，通过这样的理念来优化
经验告诉我们
当格子数等于C * 对象数时，结果会比较好；三维空间下常数C可以取27
缺陷
当细节物品在空间中分布不均匀时，存在大规模集中、大规模空白：”Teapot in a stadium” problem
*在一些场景下还是好用的，仍有在使用
内容相差不大，2022.3在2018.4的基础上做了一些补充，并去除了一个关于泛型虚方法例子。
一些平台不允许运行时的代码生成（运行时开辟内存用于存放可执行的机器指令）。因此，一切依赖于just-in-time（JIT）的托管代码（managed code）在这些平台上都无法运行。为此，你需要把所有的托管代码都进行AOT编译。在一般情况下，这个限制不会带来什么影响。但在AOT编译的平台上，也存在着一些需要额外注意的要点。
翻译自Godot引擎贡献指南，原文：best_practices_for_engine_contributors
许多代码贡献者非常的有创造力，他们享受设计抽象数据结构，搭建优秀的交互界面的过程，又或许他们只是单纯地热爱编程。代码贡献者们总是有一些很酷的想法，但这些想法或许能、或许不能解决真实的问题。
这就被称为寻找问题的解决方案。在理想的世界，它们也许并不有害，但在现实世界中，代码是需要时间去完成的，它们占用空间，而且一经存在就需要时间去维护。避免一切不必要的事物，在软件开发中一直被视作一种好的实践方式。
从21年起经过两年断断续续的开发，TableCraft终于发布了v1.0.0版本，并开始提供给项目组同事使用了。这篇文章会介绍从最初立项到最终发布TableCraft的设计发生了怎样的变化，TableCraft现阶段存在的一些问题，以及未来的发展目标。