除了运行闪光灯或在作业结束时检查CPU使用情况之外,我还能找出哪些COBOL动词更加CPU密集型?举个例子:
使用此检查语句会更有效(假设VARA是PIC X(10))
INSPECT VARA REPLACING ALL SPACE
BY HIGH-VALUE
或者写一个循环会更好
PERFORM VARYING SUB1
FROM 1 BY 1
UNTIL SUB1 > 10
IF VARA(SUB1:1) = SPACE
MOVE HIGH-VALUE TO VARA(SUB1:1)
END-IF
END-PERFORM
背景
我有一些程序正在处理具有数百万条记录的文件,而且有些作业的表现并不如我们所希望的那样好。我试图分析长时间运行的工作,并找到加速它们的非侵入性方法(如上面的更改检查循环的示例)。唯一的问题是,我实际上并不知道什么实际上更有效率。我们不想为了改变而做出改变,但如果我能以某种方式告诉改变会提高性能,我们几乎肯定会这样做。
我正在使用Z / OS 2.01.00和COBOL for Z / OS 4.2.0
答案 0 :(得分:3)
在可能和可行的情况下,我们会使用我们商店的供应商实用程序而不是编写COBOL。例如,SORT实用程序通常针对I / O进行了高度优化,并且运行良好。
可能在可维护性和效率之间进行权衡。有人认为COBOL比SORT控制卡更容易理解和调试。我认为这取决于要完成的任务的性质。
我的决策树是:
对于#2中的“合理”,一个同事在达到3个工作步骤时会放弃供应商的工具。我的限制更高。你自己的收益递减规则取决于很多因素。
答案 1 :(得分:2)
编译器高度优化了一些东西,所以一个好的起点就是确保所有这些都被打开。既然你提到Strobe,我会假设你有它。它将为您提供报告,说明哪些代码段占用了您的大部分时间,通常情况下,它不是您预期的位置,因此我会说运行这些报告并查看哪些动词导致您出现问题并尝试其他方法完成同样的事情。
在上面的例子中,INSPECT语句应该变成一个非常快速的TR指令。但是编译器可能能够通过展开它并将其转换为一系列非常快速的CLI / MVI语句,甚至可能是相同的TR指令来优化PERFORM循环。
最有可能的是,这些都不是你的问题。您可能还会查看正在处理的文件,并确保它们被正确阻止和缓冲,所有这些,通常您可以获得一些好的银行,以便在那里进行调整。
答案 2 :(得分:1)
这会使问题过于宽泛而无法处理所有内容,因此坚持INSPECT
和PERFORM
示例。
WORKING-STORAGE SECTION.
01 THE-STRING PIC X(50).
01 A-HIGH-VALUE PIC X VALUE HIGH-VALUES.
01 A-SPACE PIC X VALUE SPACE.
PROCEDURE DIVISION.
INSPECT THE-STRING
REPLACING ALL SPACE
BY HIGH-VALUE
INSPECT THE-STRING
CONVERTING ' '
TO X'FF'
INSPECT THE-STRING
CONVERTING HIGH-VALUE
TO HIGH-VALUE
INSPECT THE-STRING
REPLACING ALL A-HIGH-VALUE
BY A-HIGH-VALUE
INSPECT THE-STRING
CONVERTING A-HIGH-VALUE
TO A-HIGH-VALUE
GOBACK
.
INSPECT有多种格式。以上包括两种格式,并使用文字,比喻常量和数据名称。所有INSPECT都产生相同的结果。生成的代码......
000010 INSPECT
000544 DC31 8000 A12C TR 0(50,8),300(10) THE-STRING PGMLIT AT +292
000011 INSPECT
00054A DC31 8000 A12C TR 0(50,8),300(10) THE-STRING PGMLIT AT +292
000012 INSPECT
000550 DC31 8000 A12C TR 0(50,8),300(10) THE-STRING PGMLIT AT +292
000013 INSPECT
000556 D2FF D100 A02C MVC 256(256,13),44(10) TS2=0 PGMLIT AT +36
00055C 41E0 D100 LA 14,256(0,13) TS2=0
000560 1BFF SR 15,15
000562 BFF1 8038 ICM 15,1,56(8) A-HIGH-VALUE
000566 1AFE AR 15,14
000568 D200 F000 8040 MVC 0(1,15),64(8) A-SPACE
00056E DC31 8000 D100 TR 0(50,8),256(13) THE-STRING TS2=0
000014 INSPECT
000574 5820 905C L 2,92(0,9) TGTFIXD+92
000578 58F0 2044 L 15,68(0,2) V(IGZCIN1 )
00057C 4110 A296 LA 1,662(0,10) PGMLIT AT +654
000580 0DEF BASR 14,15
可以看出,前三个示例(编译器知道要更改的值以及要更改的内容)都会产生一个简单的TR,Translate,指令,这样就可以完全撕掉任何可能的面孔就性能而言,COBOL中的代码。
第四个做了一些工作(每次)为TR设置。第五个为运行时例程(IGZCIN1)建立参数,然后让它翻录。
所有这些都将击败你的循环。随着场地的大小延伸,情况就越多。
当然,如果你的领域很短,你有机会使用简单的IF获胜。
TR很快,但确实需要256字节的转换表。
大多数情况下,INSPECT非常迅速,并且,与所有动词一样,本质上知道所有动词的长度,因此没有机会对你自己进行编码的“再见”。
有些网站愚蠢地通过错误的思维“禁止”使用INSPECT(或者简单地说,没有想到)。可以认为对所有字符进行TALLYING很慢,但为什么要使用它?
现在,到你的PERFORM。如果你希望在循环查看每个字节的同时保持高效,不要这样做:-)
PERFORM VARYING SUB1
FROM 1 BY 1
UNTIL SUB1 > 10
IF VARA(SUB1:1) = SPACE
MOVE HIGH-VALUE TO VARA(SUB1:1)
END-IF
END-PERFORM
你有“变化”,但有什么不同?你正在看10个字节。没有什么可变的。哦,当然,它看起来更像是“代码”(来自其他语言)并节省了大量的打字。付费,每日付费: - )
MOVE ZERO TO SUB1
PERFORM LENGTH OF VARA TIMES
ADD 1 TO SUB1
IF VARA ( SUB1 : 1 ) = SPACE
MOVE HIGH-VALUE TO VARA ( SUB1 : 1 )
END-IF
END-PERFORM
(我还没有完成格式化,因为VARA在那里,并且引用修改......)
然后,假设您必须测试长于一个字节的内容,并决定使用带有INDEXED BY的OCCURS,因为它“更有效”。然而,使用文字,甚至使用LENGTH OF,您会对所产生的曲折代码感兴趣。这是因为编译器在将索引与文字进行比较时必须“标准化”索引,它必须将其从位移转换为用于比较的条目编号。使用INDEXED BY通过松弛和使用VARYING而松散(或许是全部,甚至更多),你获得了什么。
为了获得更多普遍的感觉,不仅仅是几种类型的几种INSPECT格式,你需要生成“伪装配器”,了解它正在做什么(至少在一般术语中),然后运行一些存根程序并实际比较消耗的资源,并键入以说服自己消耗差异的地方。
它不会全部出现,它是一个持续的过程,然后,当你到达Enterprise COBOL V5 +时,它会重新开始,因为一切都改变了: - )