测速强迫症

        拿一部分函数来比较一下执行速度(当然这肯定不是全部的函数)。因为我写代码比较在意在保证正确率的同时确保执行速度。

1、真实bounding函数：

我：0.43秒左右

k：5.3秒左右

大量测试后结果(上图仅以此举例)：k慢了12到20倍左右（曲线命令越多时间差距就越大）

2、普通bounding函数：

我：0.15秒左右

A3：0.26秒左右

Yutils：0.3左右

对不对比都一样的结果

大量测试后结果(上图仅以此举例)：A3和Yutils都略慢

3、绘图求总长度：

我：0.5秒左右

k：1.4秒到1.5秒左右

A3：0.36秒左右

大量测试后结果(上图仅以此举例)：k速度还是慢几倍。

4、绘图指定百分比处的点坐标： 

我：0.6秒到0.63秒左右

k：无此函数

A3：0.52秒左右

大量测试后结果(上图仅以此举例)：A3略快

5、绘图指定百分比处的点坐标（匀速化）：

我：0.62秒到0.65秒左右

大量测试后结果(上图仅以此举例)：匀速取点速度依然和原速取点差不多。此函数只有我自己的函数库有写，无其他参考

6、获取绘图路径的匀速点集：

我：3秒左右

k：19秒左右

大量测试后结果(上图仅以此举例)：k慢了6到20倍

补充：k函数这里有一个错误，就是角度计算有一个明显的错误。y=0时显然有0和π两种可能，但k函数显然只有一种结果。。

7、绘图转全直线绘图：

我：6.2秒左右

k：48.5秒左右

Yutils：11秒左右

大量测试后结果(上图仅以此举例)：k慢了6倍(一般都会慢好几倍)，但一般Yutils比 k 更快..

8、判断点包含：

我：0.22秒左右

k：1.74秒到1.8秒左右

大量测试后结果(上图仅以此举例)：k慢几倍到10几倍

补充：k函数判断点包含有较大错误，不仅自交图形判断不对，而且非自交图形一样也判断错误。猜测是kyanko前辈应该没有弄清楚assdraw的填充规则

        图233自交

比如上面的图233和图666，诸如此类的绘图，k函数均百分百会出现判断错误

9、拆字、连通域提取：

我：1.5秒左右

k：12.7秒左右

text_split：2.25秒到2.27秒左右

大量测试后结果(上图仅以此举例)：k拆字慢6到10倍

10、绘图方向判断：

我：0.09秒到0.1秒左右

k：0.62秒到0.67秒左右

大量测试后结果(上图仅以此举例)：k慢了6.5倍以上

11、封闭绘图路径：

我：0.023秒到0.03秒左右

k：0.35秒左右

大量测试后结果(上图仅以此举例)：k慢了14.6倍左右

12、开放绘图路径：

我：0.045秒左右

k：0.37秒左右

大量测试后结果(上图仅以此举例)：k慢了8倍以上

13、反转绘图路径：

我：0.22秒左右

k：0.75秒左右

大量测试后结果(上图仅以此举例)：k慢了至少3.5倍

14、任意绘图转像素

我：0.077秒到0.084秒左右

Yutils：2.215秒到2.34秒左右

k：0.66秒到0.68秒左右

大量测试后结果(上图仅以此举例)：Yutils慢8倍到30倍、k函数慢了几倍到十几倍。（曲线越多时间差距越大。因为Yutils转像素是将绘图转直线，然后再计算的，而我是直接用计算曲线和直线的交点来转像素的、并没有将曲线转为直线。）然后是k函数转像素和判断点包含同理，有较大错误、并不是真的绘图转像素（填充错误）

15、在绘图内部随机取点

我：0.122秒到0.128秒左右

k：3.1秒到3.4秒左右

大量测试后结果(上图仅以此举例)：k函数慢了几倍到几十倍(曲线越多时间差距越大)、并且该k函数不拥有灵活度(不够灵活)，我自己的函数是保证了速度以及灵活度的

        简单分析一下为什么kyanko前辈的函数几乎每一个都非常慢：

比如绘图转直线，k函数的是图1.01这么写的：

匹配的时候kyanko前辈喜欢用[a-z]，当然匹配字母可以用%a，如果写起来不麻烦怎么写都可以。其实一般匹配绘图的话，可以直接匹配[mlb]，当然这一点对代码执行速度没什么影响。。然后是为什么一定要拆开绘图字符串，然后再重连接？拆开再连接的操作一般是浪费时间的，只有在需要的时候才进行拆开的操作比较好。这里既然是转直线，那么为什么要匹配"多余的"直线命令，直接匹配出曲线进行gsub替换就可以了，匹配这个操作本身就是算比较耗时的操作了，能减少匹配还是尽量减少比较好。。还有一个很特别的就是，几乎所有类似操作的函数中，全部单独写了一个_single来专门针对一个单m，实际上，所有的single函数全部可以去除，没有实际意义，按理说辅助函数应该是有必要写才写的，没必要动不动写一个辅助函数。更何况，转直线函数中，根本不需要匹配每个m吧。。既不需要匹配m也不需要匹配l，只需要匹配b就够了。如图1.02

完全可以直接gsub每一次一口气匹配[-.%d]+ [-.%d]+ b [-.%d b]+这样每次可以一下子对当前所有曲线转直线..没有多余操作、没有多余匹配，速度会快很多很多倍。。

再比如将绘图路径封闭，k函数是图1.03这么写的：

匹配出来转数字是不太必要的操作。然后还是single这样的辅助函数完全可以去掉。主函数中，又用了拆开重组的方式，而且还用了连接符配合for来连接绘图，这个当然速度就特别慢了，就算要拆开，那把它放进表里，然后最后用table.concat连接会快很多倍。其实很多情况下，能用gsub就用gsub，不用gsub就用concat，完全不建议每次循环往后再连接一个字符串

再比如k函数中，求真实bounding的函数，图1.04、图1.05

single函数可以去掉..为什么bounding_real匹配的时候，还要match一下有没有m有没有b命令，那m就匹配两遍？如果一定要人为制造bug，直接输入一个Yutils的省略绘图，bounding函数一样会得到错误的结果，因为这个函数显然是要输入一个"标准"绘图字符串的。另外k函数中的get_command和get_pos函数没有什么实际意义，完全可以不使用这种辅助函数，而且现在还是_G全局调用..

再比如求主幅角函数，如图1.06是错误的

当y=0时，角度有0或π两种可能，但是这里y=0时只能得出一种结果...k函数有的时候选择简写有的时候又会把函数写很大一堆...

比如图1.07

为什么要自己for循环来求最大的数，一般用table.unpack即可解决相应问题。然后这个函数并没有发现实际用途，感觉也没必要作为辅助函数

再比如k函数中缩放平移等函数，如图1.08

虽然不太明白为什么要套娃，因为套了一个filter，但这当然没啥影响。不过，这里的数字全部是取的整数，那么用连接符连接就慢了，因为已经取整的数，直接用string.format('%d %d',math.round(x),math.round(y))速度会快很多很多，当然如果不用整数的话，用连接符连接会比用string.format('%s %s',x,y)要快，所以能用连接符就不建议用%s，但是如果是连接整数，就建议用%d了...

比如在绘图内部随机取点，kyanko前辈的方法是在得到像素表以后打乱整个像素表，然后在里面取几个点，这样的方法当然是非常缓慢的。kyanko前辈的函数是这么写的：

一般在绘图内取点只会取很少几个点，那么为了得到几个随机的点而打乱整个像素表就相当于白白浪费很多时间，而且kyanko前辈的这个函数也少了一点灵活度，假如要做动态效果、每一帧都要随机取几个点呢，用kyanko前辈的函数的话每一帧都要将绘图转像素，这个效率就更加低到爆炸了。所以为了保证执行速度和灵活度，该函数应该这么写：

这样将整个像素表分成几个互不重叠的区间，然后在每个区间里随机取一个点即可，这样做虽然不是完全的随机，但是对于做特效来说都是没啥区别的，这样效率上得到了极大程度的提高。并且函数也增加了灵活度，当做动态效果的时候，你可以直接给函数提供像素表，而不用每一次都把绘图给转像素！对比kyanko前辈的函数来说，既增加了执行速度又增加了函数灵活度。

还有比如，3D相关的函数执行速度很多都非常慢

比如，kyanko前辈说他没写Kshape.point_at_percent，因为遇到较大的问题，但是本身这个函数应该不难写的

比如，k函数里的to_outline转边框也是错误的

还有就是k函数库一开始的这些定义，这里面的简写好像一个都没在该函数库里用过......

因为我自己不用k函数库，所以大部分代码都没仔细看过，除了测速以外，只是后来发现k函数库几乎所有函数都特别地慢，还有不少函数有错误，也有不少算法有多余回路(比如变形函数和拆字等等的)，所以还是有一点好奇......