improvement: speed up output judging

[alphagocc]

重写了一下，4MB大小时间从22s提升到了0.04s

[alphagocc]

但我不确定代码是不是完全正确

[CoelacanthusHex]

之前是真的没想到这里会成为瓶颈

[alphagocc]

Seems that QStringView isn't very fast
at least 4x slower than std::string&
I wonder why

[CoelacanthusHex]

Seems that QStringView isn't very fast at least 4x slower than std::string& I wonder why

Maybe because it uses UTF-16, it is a variable-length encode. But std::string use no encoding, it will much faster when seek string.
So have you tried std::string_view?

[alphagocc]

std::string_view is as fast as std::string&

[CoelacanthusHex]

std::string_view is as fast as std::string&

This is expected. There are several operations where string_view is more dominant, but these are not used. string_view can reduce the complexity of some operations (such as many intermediate objects) and copying, if we use it at the beginning, we will not have to optimize some operations in the future.
The main reason we haven't used it in the past is that it was added in C++17. When this PR is merged, I will open a PR to deal with some syntactic optimizations, since Qt already requires us to use C++17.

[alphagocc]

OLE是怎么判的？

[CoelacanthusHex]

OLE是怎么判的？

之前好像没判，现在的话直接 https://doc.qt.io/qt-5/qfile.html#size 或者 https://zh.cppreference.com/w/cpp/filesystem/file_size 应该就好

[alphagocc]

这样，行尾空格和文尾换行直接OLE了

[CoelacanthusHex]

这样，行尾空格和文尾换行直接OLE了

其实主要问题在于OLE本身就没有一个判断标准，究竟要不要只考虑有效输出

[CoelacanthusHex]

我觉得 OLE 更多的是防止搞事用的，只不过必须得有一个错误类型，所以才有了 OLE