![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Axel Schwenke
Wow. 25% is a lot. Have you also tried compiling MySQL 5.6 with PGO?
No.
Because if that gets the same improvement, we haven't won anything in the comparison.
On the contrary, if the same works for MySQL 5.6 (and it seems likely it will), then we have won double - both users on MariaDB _and_ users on MySQL 5.6 will benefit from increased performance. (I know what you mean, of course, but seriously - the goal is to improve performance for as many users as possible, not to "win" in some marketing stunt. For me, it is.)
This is interesting. By definition, PGO should work best if the workload used for profiling matches the production workload. I hadn't expected that a partial match gives such good results too.
This is something that needs more tests.
Agree that more tests would be good. Even if the workload is not identical, there should be many common code paths, which would explain that there is still some improvement. If PGO would increase only one particular workload and slow down the rest, then it would be unattractive. My tests so far seem to show that this is not the case, but more testing would be good.
Yes, I'll certainly do that.
Cool. Let me know if you need any help - hopefully the procedure I wrote in the earlier mail will work for you. Note that currently, the gen_profile_load program needs the build directory to be a directory inside the source directory, IIRC (eg. mariadb-10.0/build/).
Speaking of regressions - if we plan to deliver binaries built with PGO, we must also test the influence of different architectures. I.e. how behaves a binary built on Intel when being run on AMD.
Hm, yes it would be good to test, but do you expect any issues here? I did not use any cpu-specific options, and the profiling output should be independent of the underlying cpu, I think? - Kristian.