优化程序无法优化大型函数/ switch语句 [英] Optimizer fails to optimize a large function/switch statement

查看:90
本文介绍了优化程序无法优化大型函数/ switch语句的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

MySQL解析器随着时间的推移而增长,我注意到解析器函数MYSQLparse是从解析器语法sql_yacc.yy的当前状态生成的(参见https://github.com/mysql/mysql-
Visual C ++编译器不再优化分支8.0)上的server.git。 Visual Studio 2015和2017都没有为违规功能生成优化代码。



以前版本的MySQL中的MySQL解析器(例如,参见上面github存储库中的5.7版本)
由Visual C ++编译器优化:违规函数的大小在MySQL版本之间有所增加,所以我想知道解析器函数的大小是否阻止优化器完成其工作。 


事实证明,减少违规函数的大小确实"重新启用"优化器。 MYSQLparse函数的大部分是一个带有大约2000个案例标签的switch语句,如果我注释掉足够数量的案例
(删除大约270个案例似乎可以做到这一点),编译器可以更好地优化保留未注释的代码。 显然,注释掉代码不是一个解决方案 - 我只是将这种技术用作粗略的测试,看看我对函数/ switch
语句大小的猜测是否合理影响优化器行为。


<那么现在我的问题变成了 - 有没有办法说服优化者"更加努力"。在处理特定功能或翻译单元时(可能花费更多时间/记忆)?


谢谢&问候,


Dan Blanchard


解决方案

显然,根据YACC / Bison生成的语法的MySQL解析器的低效率已经成为至少十年的关注点;请参阅
MySQL错误:#29921:MYSQLparse在MySQL 5.0中使用的CPU比在MySQL 4.0中的yyparse多3倍。您需要创建一个MySQL错误报告,以便MySQL专家可以处理它。一个巨大的转换语句应该将
转换为更高效的东西。专家需要开发一种对计算机和人类都有效的更有效的解决方案。


不是每个人都理解YACC / Bison。你不应该假设这里的人理解。链接到MySQL源代码没有帮助;我们中很少有人会去搜索所有的源代码。我在该页面上找不到MYSQLparse,我忘记了YACC / Bison生成的代码的详细信息
。我可以参考我之前的研究,但我们不应该追捕它;你应该在相关代码的规范中非常精确。然而,这并不重要,因为我认为Visual Studio专家在这里达成共识是需要由MySQL专家解决,以获得更加永久和通用的解决方案。


The MySQL parser has grown over time, and I've noticed that the parser function MYSQLparse generated from the current state of the parser grammar sql_yacc.yy (see https://github.com/mysql/mysql-server.git on branch 8.0) is no longer being optimized by the Visual C++ compiler. Neither Visual Studio 2015 nor 2017 produce optimized code for the offending function.

The MySQL parser in previous versions of MySQL (for example, see version 5.7 in the github repository above) is optimized by the Visual C++ compiler: the size of the offending function has increased somewhat between MySQL versions, so I wondered if the sheer size of the parser function was preventing the optimizer from doing its job. 

It turns out that reducing size of the offending function does "re-enable" the optimizer. The bulk of the MYSQLparse function is a switch statement with around 2000 case labels, and if I comment out a sufficient number of cases (removing around 270 cases seems to do the trick) the compiler does a better job of optimizing the remaining uncommented code.  Obviously, commenting out code is not a solution - I just used this technique as a crude test to see if my guess about function/switch statement size influencing the optimizer behaviour was plausible.

So now my question becomes - is there any way of persuading the optimizer to "try harder" (perhaps expending more time/memory) when working on a particular function or translation unit?

Thanks & regards,

Dan Blanchard

解决方案

Apparently the inefficiency of the MySQL parser rooted in the YACC/Bison generated grammar has been a concern for at least a decade; see MySQL Bugs: #29921: MYSQLparse uses 3X more CPU in MySQL 5.0 than yyparse in MySQL 4.0. You need to create a MySQL bug report so the MySQL experts can deal with it. A switch statement that huge should be converted to something more efficient. The experts need to develop a more efficient solution that is efficient for both the computer and the humans.

Not everyone understands YACC/Bison. You should not assume people here understand. Linking to the MySQL source code does not help; very few of us are going to hunt through all the source code. I can't find MYSQLparse on that page and I forget the details of the code generated by YACC/Bison. I could refer to my previous studies but we should not have to hunt it down; you should be very precise in the specification of the relevant code. However that does not really matter because I think the consensus here from the Visual Studio experts is that this needs to be solved by the MySQL experts for a more permanent and universal solution.


这篇关于优化程序无法优化大型函数/ switch语句的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆