Optimization 在TI-BASIC中优化代码真的会有所不同吗？

我知道，在TI-BASIC中，惯例是痴迷地进行优化，并尽可能多地节省位（我承认这很有趣）

比如说,

DelVar Z
Prompt X
If X=0
Then
    Disp "X is zero"
End                   //28 bytes

会被清理干净的

DelVar ZPrompt X
If not(X
    "X is zero        //20 bytes

---

但是，这样优化代码真的会有所不同吗？它是否明显运行得更快或节省内存？

TI-BASIC

是一种解释语言，这通常意味着每个操作都会有巨大的开销

解释语言的工作方式是，不是将程序编译成直接在CPU上运行的代码，而是每个操作都是对解释程序的函数调用，它查看需要执行的操作，然后调用函数来完成这些子任务。在大多数情况下，开销是速度的一两个因素，通常也是堆栈内存使用的两个因素。但是，非堆栈的内存通常是相同的

在上面的示例中，您正在执行完全相同数量的操作，这意味着它们的运行速度完全相同。您应该优化的是

i=i+1

，这是4个操作，而

i++

是2个操作。（例如，

TI-BASIC

不支持

++

运算符）

这并不意味着所有操作都需要完全相同的时间，在内部，一个操作可能会调用数百个其他函数，也可能像更新单个变量一样简单。解释器的程序员可能还实施了各种窥视孔优化，以优化非常特定的语言结构，例如，

for（int i=0；i

都可以实现为一组昂贵的解释器函数，其行为就好像

i

是泛型的，或者它可以优化为一个编译循环，只需更新变量

i

，然后重新计算

计数

现在，并不是所有的解释语言都注定会有这种苍白的存在。例如，

JavaScript

曾经是其中之一，但是现在所有主要的js引擎都会将代码编译成直接在CPU上运行

---

更新：澄清并非所有操作都是平等的。

是。优化您的TI Basic代码会产生差异，并且这种差异比大多数编程语言的差异要大得多

在我看来，TI Basic程序最重要的优化是大小（使其尽可能小）。这对我来说很重要，因为我的计算器上有几十个程序，只有24KB的用户可访问RAM。在这种情况下，实际上没有必要花费大量时间来节省几个字节的空间；相反，我只是建议学习最短、最有效的方法，这样当你编写程序时，它们自然会变得很小

此外，TI Basic程序应针对速度进行优化。我头顶上的例子包括未关闭的

For（

循环的怪癖，在循环的每次迭代中计算一次值而不是计算它（如果可能的话），以及在必须多次访问变量时使用快速访问的变量，如

Ans

和财务变量（如1000+）

第三种可能的优化是运行时内存使用量。每个循环、函数调用等都有一个开销，必须存储在内存堆栈中，以便在程序执行期间返回原始位置、计算值等。避免内存泄漏非常重要（例如用

Goto

打破循环）

由您决定如何平衡这些优化。我更喜欢：

首先，保证我的程序中没有内存泄漏或错误嵌套的循环

利用对程序速度影响很小或没有影响的任何大小优化

考虑速度优化，并确定增加的速度是否值得增加程序大小

---

当然，这是有区别的。我为TI-84+CSE编写了一个全尺寸彩色RPG，我告诉你，如果不优化我的任何代码，游戏将完全无法运行。目前，在CSE上，Uvutu的魔法只能在其他所有程序都已存档且所有其他内存均已耗尽的情况下运行。仅程序和数据存储在RAM中占用20k字节，或者在所有可用用户内存下仅占用1kb。由于使用了所有变量，内存接近危险的低点。在我的开发过程中，由于糟糕的优化，我甚至无法启动游戏而不获得“全部内存”错误。我计划实施各种额外的东西，但由于空间和速度的考虑，这是不可能的。这只是对空间的考虑

在速度部门，游戏在超世界变得很慢，现在仍然如此。与其他游戏相比，在超世界中行走的速度非常慢，这是因为我在代码中必须做的事情；我必须检查碰撞，检查用户是否正在移动到新地图，检查他们是否按下了一个键，该键会导致非法响应，check如果战斗继续下去，还有更多。我能够对行走速度进行轻微的优化，但即使如此，我可以明目张胆地说我已经有所改进。它仍然非常慢（至少与我所做的其他端口相比），但我让它更能忍受

总之，通过我自己制作一个大型项目的经验，我可以说在TI Basic中，优化代码确实起到了作用。其他答案也提到了这一点，但TI Basic是一种解释语言。这意味着代码不会被编译成更快、更低级别的代码，而是在程序执行时直接读取程序中的内容s、 由解释器解释，调用执行命令所需的子例程和其他内容，然后返回