关于blobmid和getbytearray效率

关于blobmid和getbytearray效率

最近做一个关于json字符串的解析(pb这方便无法和php这样的网络语言相媲美，只能diy).

例如{"aa":1,"bb":2,"cc":3,"dd":"abc","childtable":{"aa":1,"bb":2}}

返回字符串为utf8编码。所以没法直接用pb的sring(12.5来处理)我用的是blob+byte。只在取得colname和content的起止位置后，才用string(blobmid(blob,begin,end -begin+1)来取。并根据datatype做转换后存入到dw中。然后update。

将aa，bb，cc这样的栏位名做到一个table中，并做上datatype。string(varchar)类型的会带引号，其他类型无引号。

因为怕遍历blob太慢，所以用了byte[]来遍历字节

当返回的字符串很短时，约60000以下，解析非常顺序，而且效率非常好。几千笔资料也只需两三分钟(字段多，而且还有附加的信息表)。但是如果长度超长，比如1000000字节，问题就来了，解析时进度非常缓慢，约1-2行每秒，耗时会超过40分钟。最开始怀疑内存回收问题，又用函数回收内存，仍然不行。所以最终怀疑是byte[]的遍历效率出现问题，或者是blobmid截取字符串时出现了问题。改为：

当字符串长度大于60000时，每解析一行，就重新截取一个固定长度(这个长度要大于一行的长度,避免遍历到边界出错）。这样观察下来，效率非常好，可以达到其他字符串较短的那种解析效率（每秒10-30行：*上百个栏位,字段名有点长).已经满足需求。

需要说明的是，仿佛blobmid和getbytearray的效率比较高，和解析json字符串的耗时想比，可以忽略不计。

顺便说json的缺点，json都带栏位，而且每行的栏位可以不同。比如null值的不输出来。但是标准设计的表格，如果字段太多，或者字段名太长(我的案例中会长达48个字符).这样增加了返回字符串的长度，而且重复N次。特别给解析带来不必要的麻烦。对于colname其实只要区分出不同即可。比如约定用栏位的顺序来返回：

{"1":1,"2":2,"3",3} 这样解析起来一定效率非常好。

另外如果返回的栏位是每个栏位都固定的话，也可以在遍历时按字段出现的顺序直接跳过栏位的宽度。不过如果栏位不固定(比如NULL的字段不输出)那就没办法，只能老老实实挨个遍历，效率很低。