REXX 中 length() 的处理开销是多少?

发布于 2024-07-10 12:33:09 字数 181 浏览 12 评论 0原文

REXX中length()函数的处理开销如何随字符串长度变化?


更新:我正在使用:

  • uni-REXX (R) 版本 297t
  • Open-REXX (TM) 版权所有 (C) iX Corporation 1989-2002。 版权所有。

How does the processing overhead of the length() function in REXX change with the length of the string?


Update: I'm using:

  • uni-REXX (R) Version 297t
  • Open-REXX
    (TM) Copyright (C) iX Corporation
    1989-2002. All rights reserved.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

娇女薄笑 2024-07-17 12:33:09

开销为 0。长度存储在描述符中。

尼尔·米尔斯特德
uni-REXX 的作者(不是开玩笑)。

The overhead is 0. The length is stored in a descriptor.

Neil Milsted
Author of uni-REXX (no kidding).

辞旧 2024-07-17 12:33:09

这完全取决于实施。 您是指 REXX for OS/2、REXX for z/VM、REXX for z/OS、OOREXX for Windows、REXX/400 或 Regina?

IBM 的 REXX 语言规范中没有任何内容规定该函数是如何在幕后实现的,如果扫描字符串,则可能是 O(N);如果长度与字符串一起存储在某处,则可能是 O(1)。

如果它确实很重要,最好使用基准测试代码进行测试,看看长度是否会产生影响。

It depends entirely on the implementation. Do you mean REXX for OS/2, REXX for z/VM, REXX for z/OS, OOREXX for Windows, REXX/400 or Regina?

Nothing in the REXX language specs out of IBM dictate how the function is implemented under the covers, it could be O(N) if you scan the string or O(1) if the length is stored with the string somewhere.

If it's really important, best to test with benchmarking code to see if the length makes a difference.

原野 2024-07-17 12:33:09

我不知道。 我曾经写过一些 Rexx,但我从未遇到过 length() 函数的性能问题。 这种扩展方式甚至可能取决于您对 Rexx 解析器的实现。

我会编写一个 Rexx 脚本,在 10 个字符的字符串上对“length()”进行 10.000 次调用,然后在 100 个字符的字符串上,然后在 1000 个字符的字符串上进行 10.000 次调用。

在图表中绘制结果时间将为您提供性能下降情况的近似值。

说了这么多,我的猜测是性能下降最多是线性的,如 O(n) 所示。 (参见http://en.wikipedia.org/wiki/Big_O_notation

I'm not sure. I've written some Rexx in my days but I've never had performance trouble with the length() function. The way this scales is probably even depending on your implementation of the Rexx parser.

I'd write a Rexx script that times 10.000 calls of "length()" on a 10-character sting, then on a 100 character string, and then on a 1000 character string.

Plotting the resulting times in a graph would give you an approximation on how performance decreases.

Having said all this, my guess is that performance decrease is at most linear, as in O(n). (See http://en.wikipedia.org/wiki/Big_O_notation)

心碎无痕… 2024-07-17 12:33:09

这是特定于语言实现的。 我已经很久没有写 REXX 了,事实上我写了 AREXX(Amiga 实现),那是 15 年前的事了。 :-)

您可以编写自己的测试例程。 生成长度不断增加的字符串,并使用高性能计时器测量获取 length() 所需的时间。 如果您将时间和字符串长度存储在基于逗号分隔表的文本文件中,则可以使用 gnuplot 绘制它。 然后你会非常清楚地看到它是如何扩展的。

编辑:我应该先检查罗尔夫的答案,因为他或多或少写了同样的东西。 :-)

It's language implementation specific. It was a long time since I wrote any REXX now, in fact I wrote AREXX (the Amiga implementation) and it was 15 years ago. :-)

You can write your own test routine. Generate strings of increasing length and measure the time it takes to get length() using a high performance timer. If you store the times and string lengths in a text file based comma separated table you can then plot it using gnuplot. And then you'll see very clearly how it scales.

Edit: I should have checked Rolf's answer first since he wrote more or less the same thing. :-)

初与友歌 2024-07-17 12:33:09

我可以谈论 IBM Mainframe 版本、OS/2 的 Classic Rexx 版本以及任何 Object Rexx 实现。 长度存储在字符串描述符中,因此开销与字符串长度无关。

I can speak for the IBM Mainframe versions, the Classic Rexx version for OS/2, and any of the Object Rexx implementations. The length is stored in the string descriptor, so the overhead is independent of the string length.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文