吉里吉里1/吉里吉里2中KAG脚本的解释执行(1)

从我开始关注吉里吉里2这个引擎开始，就一直看到关于“KAG的执行效率比TJS2低很多”的说法。但是到底慢多少呢？没见到过具体测评。
有机会的话我看看设计一个测评方法好了。关键是看看eval,iscript这两个标签里的表达式执行效率与真正的TJS2有多少差距。不过在那之前，我们可以看看“KAG比TJS慢”这种说法在吉里吉里引擎发展过程上的根源。

======================================================================

回到2001年，当时的吉里吉里只发展到吉里吉里1，具体版本号吉里吉里0.91/KAG 2.3；要执行KAG 2.3的吉里吉里本体至少要达到0.89.6.1512版本。当时的KAG脚本是如何被解释执行的呢？

\system\KAGMain.tjs/3384行: function getNextLine()
\system\KAGMain.tjs/3472行: function getCurrentElement()
\system\KAGMain.tjs/3641行: function getNextElement()
\system\KAGMain.tjs/2610行: function process(storage="",start="",incflag=true, run=true, immediate=false)
\system\KAGMain.tjs/3771行: function processOne()
这几个就是构成KAG解释/执行系统的主要函数，加上在KAGMain.tjs里的其它函数，构成了KAG系统的执行核心。这个核心与system目录里的其它TJS脚本合在一起，则构成了完整的KAG系统。

可以看到，吉里吉里1里的KAG系统是完全由TJS脚本实现的。其中在MainWindow.processOne()里，有这样的代码片段：
[code]function processOne()
{
// 省略...local variable declaration
// 省略...beginning of try block

while(true)
{
// 省略...element type checking

switch(elm.type)
{
case 'jump': // jump !
{
var count=true;
count=+elm.countpage if elm.countpage!==void;
process(elm.storage, elm.target, elm.countpage, true, true);
return;
}
case 'call': // call
processCall(elm);
return;
case 'return': // return
{
var count=true;
count=+elm.countpage if elm.countpage!==void;
processReturn(elm.storage, elm.target, count);
chTimer.interval = 1;
nextResetChTimer = true;
return;
}
case 'image': // image !
case 'img':
loadLayerImage(elm);
break;

// 省略...a few tags

case 'eval': // evaluate !
parseExpression(elm.exp);
break;

// 省略...rest of the switch
} // end of switch
} // end of while

// 省略...error handling
} // end of function[/code]
于是可以很明确的看出，吉里吉里1中的KAG系统的执行核心是一个switch dispatch loop，KAG脚本由TJS解释执行；而用于实现KAG系统的TJS又由底层的吉里吉里1本体解释执行。我手上没有吉里吉里1核心部分的源代码，不太清楚当时TJS是如何被解释的，不过想来其执行效率肯定没有现在的TJS2高；可以想像当时的KAG系统与现在相比肯定是慢很多。

进入到吉里吉里2时期后，为了解决KAG系统的性能问题，其核心解释执行部分被移动到了吉里吉里2本体中，以C++代码实现。
吉里吉里2的源代码中，
\kirikiri2\src\core\utils\KAGParser.h
\kirikiri2\src\core\utils\KAGParser.cpp
这两个文件定义了TJS2中可以使用的KAGParser这个native class。但在这对C++源代码里却找不到KAG系统里用到的tag。它们跑哪里去了呢？

在原版KAG系统（2.28稳定版）中，\system\MainWindow.tjs/4551行，
或者在KAGEX（同样在2.28稳定版）中，\system\MainWindow.tjs/5770行，
[code]function getHandlers()
{
return %[ // 关联数组对象

/*
处理函数数组是名字/函数对的枚举，以
函数名 : function(elm)
{
// 函数内容
} incontextof this,
的格式来表示。但是，如果函数名是保留字，
则不使用“函数名 : ”而使用“"函数名" => ”为开头。
为了让函数正确使用这个类为上下文运行，
incontextof this是必要的。
*/

//--------------------------------------- 处理函数数组群(消息操作) --

// 省略...部分tag

endline : function(elm)
{
// 改行模式在一行末尾调用的处理
return 0;
} incontextof this,

dispname : function(elm)
{
if (elm !== void) {
var name = elm.disp !== void ? elm.disp : elm.name;
if (name !== void) {
return tagHandlers.origch(%["text" => "【" + elm.name + "】"]);
}
}
return 0;
} incontextof this,

// 省略...部分tag

//--------------------------------------- 处理函数数组群(变量、TJS操作) --

eval : function(elm)
{
// 计算表达式
Scripts.eval(elm.exp);
return 0;
} incontextof this,

// 省略...剩余tag

//----------------------------------------------- 处理函数数组结束 --

interrupt : function(elm) { return -2; } incontextof this ];
} // end of function[/code]
这里，MainWindow内定义了一个函数，用于获取一个关联数组，这个数组里元素是tag名与其对应的处理函数。在构造MainWindow对象时，这个关联数组会被作为参数用于构造一个Conductor对象。注意到，Conductor类继承于BaseConductor类，而BaseConductor类继承于上面提到的KAGParser。

在原版KAG系统（2.28稳定版）中，\system\Conductor.tjs/433行，
或者在KAGEX（同样在2.28稳定版）中，在\system\Conductor.tjs/441行，
[code]function onTag(elm)
{
// tag的处理
var tagname = elm.tagname;
var handler = handlers[tagname];
if(handler !== void)
{
var ret = handler(elm);
lastTagName = tagname;
return ret;
}
return onUnknownTag(tagname, elm);
}[/code]
这样就可以知道，吉里吉里2中KAG系统有部分的核心被移动到了吉里吉里2本体中以提高运行效率，而具体与tag对应的操作依旧以TJS2实现。
由于吉里吉里2中的关联数组实现比吉里吉里1中的更高效，并且在tag的处理上以table-driven的方式替代了吉里吉里1中的大switch语句，运行起来应该是更快的。但其本质并没有改变：每个KAG脚本中的tag都是一个对TJS定义的函数的调用。
要在KAG脚本里实现相同的（复杂）功能，一般有两种选择：1、以iscript块嵌入TJS脚本，并将其注册为一个插件；或者直接把一些KAG tag组合在一起写成一个macro。从上面的分析应该能看到，使用嵌入的iscript将比简单的使用macro有更精确的控制，因而也确实会更加有效。
如果感到在KAG系统有什么功能会经常被用到，但原本的KAG系统并没有提供，也有另外一种方法来修改：直接在MainWindow.tjs的getHandlers()函数里添加需要的tag与其对应的处理函数。这又比在KAG脚本中嵌入iscript快要更直接，代价是对KAG系统有侵入性。

======================================================================

回到前面提到的，嵌入在KAG脚本中的iscript块的执行问题，在吉里吉里2中有这样的代码片段：
\kirikiri2\src\core\utils\KAGParser.cpp/1070行: bool tTJSNI_KAGParser::SkipCommentOrLabel()中
[code]if(p[0] == TJS_W('[') &&
(!TJS_strcmp(p, TJS_W("[iscript]")) ||
!TJS_strcmp(p, TJS_W("[iscript]\\")) )||
p[0] == TJS_W('@') &&
(!TJS_strcmp(p, TJS_W("@iscript")) ) )
{
// inline TJS script
if(RecordingMacro)
TVPThrowExceptionMessage(TVPLabelOrScriptInMacro);

ttstr script;
CurLine++;

tjs_int script_start = CurLine;

for(;CurLine < LineCount; CurLine++)
{
p = Lines[CurLine].Start;
if(p[0] == TJS_W('[') &&
(!TJS_strcmp(p, TJS_W("[endscript]")) ||
!TJS_strcmp(p, TJS_W("[endscript]\\")) )||
p[0] == TJS_W('@') &&
(!TJS_strcmp(p, TJS_W("@endscript")) ) )
{
break;
}

if(ExcludeLevel == -1)
{
script += p;
script += TJS_W("\r\n");
}
}

if(CurLine == LineCount)
TVPThrowExceptionMessage(TVPKAGInlineScriptNotEnd);

// fire onScript callback event
if(ExcludeLevel == -1)
{
if(Owner)
{
tTJSVariant param[3] = {script, StorageShortName, script_start};
tTJSVariant *pparam[3] = { param, param+1, param+2 };
static ttstr onScript_name(TJSMapGlobalStringMap(TJS_W("onScript")));
Owner->FuncCall(0, onScript_name.c_str(), onScript_name.GetHint(),
NULL, 3, pparam, Owner);
}
}

continue;
}[/code]
可以看到，iscript块的执行其实与TJS2普通的全局脚本一样，是直接通过TJS2 VM来完成而没有太多经过别的处理。从这点看，无论是普通的TJS2代码还是嵌入在KAG脚本中的TJS2代码，在执行效率上都应该差不多。