问题如下
文本文件包含数百万行算法 - 需要快速评估
我一直在探索这个问题的选项，并使用漂亮的exprtk C++库编写了一个小脚本。
代码工作并能够评估表达式，但比我想象的要慢。算术线可能会很长，这可能会使问题复杂化。出于兴趣，我将评估时间与基本Python eval()命令的评估时间进行了比较，并且惊讶地发现eval()比exprtk快3-4倍！
以下是C++代码：
#include <iostream>
#include <fstream>
#include <cstdio>
#include <sstream>
#include <string>
#include "exprtk.hpp"
int main()
{
typedef exprtk::symbol_table<double> symbol_table_t;
typedef exprtk::expression<double> expression_t;
typedef exprtk::parser<double> parser_t;
typedef exprtk::parser_error::type error_t;
// Define variables in strings
double A = 1.1;
double B = 2.2;
double C = 3.3;
double m3 = 1.0;
double z3 = 2.0;
symbol_table_t symbol_table;
symbol_table.add_constants();
symbol_table.add_variable("A", A);
symbol_table.add_variable("B", B);
symbol_table.add_variable("C", C);
symbol_table.add_variable("m3", m3);
symbol_table.add_variable("z3", z3);
expression_t expression;
expression.register_symbol_table(symbol_table);
parser_t parser;
// Load the text file and loop over the lines
std::ifstream fin("test.txt");
std::string file_line;
while(std::getline(fin, file_line)) {
// current line of text is in file_line, not including the \n
std::string expression_str = file_line;
if(!parser.compile(expression_str, expression)) {
printf("Error: %s\tExpression: %s\n", parser.error().c_str(), expression_str.c_str());
for(std::size_t i = 0; i < parser.error_count(); ++i) {
const error_t error = parser.get_error(i);
printf("Error: %02d Position: %02d Type: [%s] Msg: %s Expr: %s\n",
static_cast<int>(i),
static_cast<int>(error.token.position),
exprtk::parser_error::to_str(error.mode).c_str(),
error.diagnostic.c_str(),
expression_str.c_str());
}
return 1;
}
double result = expression.value();
printf("%10.16f\n", result);
}
return 0;
}
这是Python代码：
with open("test.txt", 'r') as h:
linesHH = h.readlines()
// Apply list comprehension
matt = [eval(x) for x in linesHH]
文本文件具有非常基本的格式，新的算术行跟随另一行。第一行的示例如下：
-10./(A+B)^4-2.500000000000000*A^3/C^3/(A+B)^4-9.250000000000000*A/C/(A+B)^4-2.500000000000000*B^3/C^3/(A+B)^4-9.250000000000000*B/C/(A+B)^4-8.*A^2/C^3/(A+B)^4-8.*B^2/C^3/(A+B)^4-1.750000000000000*A/B/(A+B)^4+2.250000000000000*B^2/C^2/(A+B)^4-1.750000000000000/A*B/(A+B)^4-1./A^2*B^2/(A+B)^4-.2500000000000000/A^3*B^3/(A+B)^4-13.*A/C^2/(A+B)^4-13.*B/C^2/(A+B)^4-.2500000000000000*A^3/B^3/(A+B)^4+2.250000000000000*A^2/C^2/(A+B)^4-1.*A^2/B^2/(A+B)^4+62./C/(A+B)^4*z3-11./C/(A+B)^4-13.*A^2*B/C^3/(A+B)^4+3.500000000000000*A^2/B/C/(A+B)^4-13.*A*B^2/C^3/(A+B)^4+3.500000000000000/A*B^2/C/(A+B)^4-14.*A*B/C^3/(A+B)^4-.5000000000000000/A*B^4/C^3/(A+B)^4-1./A*B^3/C^2/(A+B)^4-.2500000000000000/A^2*B^4/C^2/(A+B)^4-2./A^2*B^3/C/(A+B)^4-.2500000000000000/A^3*B^4/C/(A+B)^4-1.*A^3/B/C^3/(A+B)^4-.5000000000000000*A^3/B^2/C^2/(A+B)^4-2.500000000000000*A^2/B/C^2/(A+B)^4-.5000000000000000*A^2/B^2/C/(A+B)^4-2.*A/B/C/(A+B)^4-1./A*B^3/C^3/(A+B)^4-2.500000000000000/A*B^2/C^2/(A+B)^4-2./A*B/C/(A+B)^4-.5000000000000000/A^2*B^3/C^2/(A+B)^4-.5000000000000000/A^2*B^2/C/(A+B)^4-.5000000000000000*A^4/B/C^3/(A+B)^4-.2500000000000000*A^4/B^2/C^2/(A+B)^4-.2500000000000000*A^4/B^3/C/(A+B)^4-1.*A^3/B/C^2/(A+B)^4-2.*A^3/B^2/C/(A+B)^4-18.*A*B/C^2/(A+B)^4+26.*A/C^2/(A+B)^4*z3+26.*B/C^2/(A+B)^4*z3+11.*A/B/C/(A+B)^4*z3+5./A*B^2/C^2/(A+B)^4*z3+11./A*B/C/(A+B)^4*z3+1/A^2*B^3/C^2/(A+B)^4*z3+5./A^2*B^2/C/(A+B)^4*z3+1/A^3*B^3/C/(A+B)^4*z3+A^3/B^2/C^2/(A+B)^4*z3+A^3/B^3/C/(A+B)^4*z3+5.*A^2/B/C^2/(A+B)^4*z3+5.*A^2/B^2/C/(A+B)^4*z3
我应该对此感到惊讶吗？ 我很惊讶，因为阅读文档突出显示eval（）很慢并且通常应该避免（主要是由于其固有的安全问题），但在这个特定的例子中，它似乎比我的代码表现更好。
我不相信exprtk是线程安全的，所以我怀疑多线程有很多选择。
为了加快速度，可以采用分流码算法和反向波兰表示法，但仅从这个比较中我对C++和Python之间的速度差异感到惊讶。这种速度差异有明显的原因吗？
exprtk中是否有更多的开销，或者我的代码只是完全垃圾？可能是后者......
修改
我使用exprtk库的原因是阅读this数学解析器基准测试调查。