逻辑地址转换成物理地址

某计算机系统页面大小为 2K，进程 P1 的页面变换表如下所示，若 P1 要访问数据的逻辑地址为十六进制 1B1AH，那么该逻辑地址经过变换后，其对应的物理地址应为十六进制(231AH)。

解题步骤

将逻辑地址 1B1AH 转换为二进制（H 表示十六进制）:
1B1AH = 0001 1011 0001 1010 (B)
由于页面大小为 2K = 2048 = 2^11 字节，所以页内偏移量占用 11 位，页号占用剩余的位。
页号: 0001 1 (B) = 3 (D)
页内偏移量: 011 0001 1010 (B) = 31AH
根据页面变换表，页号 3 对应的物理块号为 4，4 转换为二进制为 100（B），后面拼接上面的页内偏移量，就可以得出物理地址。
物理地址的计算:
100 011 0001 1010（B）转换为十六进制为 231AH。

万字长文吐血整理，建议点赞收藏，细细品味。

今天翻译的文章是 《Optimizing Javascript for fun and for profit》，作者 Rom Grk。文中深入探讨了 13 个不为人知的 JavaScript 高级优化技巧。通过实际案例和详细的解释，揭示了如何通过深入理解 JavaScript 引擎的工作原理来提升代码性能。同时，强调了基准测试的重要性，并提供了一些工具和策略，帮助开发者进行基准测试。以下是文章的全文翻译：

我常常感觉，如果得到适当的优化，JavaScript 代码通常可以运行得更快。我在这里总结了一些有用的常见优化技术。需要注意的是，性能提升往往以可读性为代价，因此我把在性能和可读性之间做选择的问题留给读者。我还要指出，谈论优化就必然要谈论基准测试。如果一个函数在整体运行时间中只占很小一部分，那么花几个小时对其进行微调，使其运行速度提高 100 倍是没有意义的。如果正在进行性能优化，第一步也是最重要的一步是基准测试。我将在后面的要点中介绍这个话题。同时请注意，微基准测试通常是有缺陷的，这里介绍的也可能包括在内。我已经尽力避免这些陷阱，但在没有基准测试的情况下，不要盲目使用此处提出的任何要点。

在 JavaScript 开发中，垃圾回收和闭包是两个常见但容易被忽视的技术细节。表面上，它们的工作机制看似简单，但在特定情况下，它们可能会导致内存泄漏，甚至影响应用的性能。

作者 Jake Archibald 在 《Garbage collection and closures》一文中通过真实的代码示例，深入剖析垃圾回收与闭包之间的复杂关系，帮助你了解如何避免内存泄漏，写出更高效、更可靠的代码。

以下是文章的全文翻译：

我和 Surma、Jason 一起开发时，发现函数内的垃圾回收并不像我们预期的那样工作。

1
2
3
4
5
6
7
8
9
10

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);
  const id = setTimeout(() => {
    console.log(bigArrayBuffer.byteLength);
  }, 1000);

  return () => clearTimeout(id);
}

globalThis.cancelDemo = demo();

想必每个程序员都对 git 非常熟悉，但是你是否知道 .git 目录的结构和每个部分的作用呢？今天我翻译的文章是《Inside .git》，作者是 Julia Evans。文章详细介绍了 Git 版本控制系统中的 .git 目录的结构和每个部分的作用。以下是对文章的全文翻译，为便于理解，部分内容可能稍作修改：

你好！这周我在 Mastodon 上发布了一个关于 .git 目录里有什么内容的漫画，有人想要文字版，于是诞生了这篇文章。我还添加了一些额外的注释。下面是漫画图片。它用大约 15 个词解释了你的 .git 目录的每个部分。

如果你想自己运行这些例子，可以使用 git clone https://github.com/jvns/inside-git。

开发人员编写 JavaScript 代码；浏览器执行 JavaScript 代码。从根本上说，在前端开发中并不需要构建步骤。那么，为什么现代前端开发中会有构建步骤呢？

随着前端代码库的不断增长，以及开发人员工效变得越来越重要，直接将 JavaScript 源代码发送给客户端会导致两个主要问题：

1. 不支持的语言特性： 因为 JavaScript 在浏览器中运行，而且市面上有多种版本的浏览器，你使用的每一种语言特性，都会减少能够执行你的 JavaScript 的客户端数量。此外，像 JSX 这样的语言扩展不是有效的 JavaScript，不能在任何浏览器中运行。

2. 性能问题： 浏览器必须单独请求每个 JavaScript 文件。在大型代码库中，这可能导致需要数千个 HTTP 请求来渲染一个页面。在过去，HTTP/2 出现之前，这还会导致数千次 TLS 握手。

此外，可能还需要几次连续的网络往返才能加载完所有的 JavaScript。例如，如果 index.js 导入了 page.js，而 page.js 又导入了 button.js，那么就需要三次连续的网络往返才能完全加载 JavaScript。这被称为瀑布流问题。

源文件也可能因为长变量名和空白缩进字符而变得不必要地大，增加了带宽使用和网络加载时间。

前端构建系统处理源代码，并输出一个或多个为发送到浏览器而优化的 JavaScript 文件。生成的分发版通常对人类来说是难以理解的。