Bug #70402 new deprecation warnings introduce unwanted performance degradation side-effect

• Submitted: 23 Sep 2013 21:35
• Modified: 12 Nov 2013 1:47
• Reporter: Shane Bester (Platinum Quality Contributor)
• Status: Closed
• Category: MySQL Server: Errors
• Severity: S5 (Performance)
• Version: 5.7.2
• OS: Any
• CPU Architecture: Any

[23 Sep 2013 21:35] Shane Bester

Description:
For example:
https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_encode

The ENCODE/DECODE function recently got a warning added to the output.
Problem is, the warning construction takes more time that the function.

Query runs in the following times:

5.7.2:  44.09 sec
5.6.14: 18.50 sec
5.5.32: 18.64 sec

How to repeat:
select benchmark(100000000,encode('abcdefghij','stringt')),version();

Suggested fix:
How do we disable generation of useless warnings?

[23 Sep 2013 21:41] MySQL Verification Team

5.7.3 profile

Attachment: bug70402.png (image/png, text), 24.71 KiB.

[23 Sep 2013 21:55] MySQL Verification Team

i wonder why we use expensive *sprintf* type of functions when a static string could somehow be constructed at compile time?

[4 Oct 2013 8:25] Tor Didriksen

The WARN_DEPRECATED macro evaluates to this:
if (((THD *) thd) != __null) push_warning_printf(((THD *) thd), Sql_condition::SL_WARNING, 1287, _current_thd()->variables.lc_messages->errmsgs->errmsgs[(1287) - 1000], ("DECODE"), ("AES_DECRYPT"));

As you can see, we do a lookup in some error message array.
I presume this can be configured at runtime to select warnings in different languages.

The use of _current_thd, should go away though.

[12 Nov 2013 1:47] Paul DuBois

Noted in 5.7.3 changelog.

Overhead for deprecation warnings was reduced.