Performance MySQL connector for .NET, discuss?

Question

.NET

Recently, when translating a project from .net core 3.1 to 5.0, I decided to switch from Pomelo.EntityFrameworkCore.MySql to the official MySQL connector (MySql.Data.MySqlClient) and came across a sharp drop in application performance.

Interested and tested. The difference in data proofreading speed was 10-30 times depending on the test conditions.
The tests were carried out on a local basis and on a simple request to minimize delays from the MySQL server. Tested on Windows and Ubuntu, on .net core 3.1 and .net core 5 - the results are comparable.

Here is the test code, it is the same for both libraries.

List<uint> ids = new List<uint>();
            using (MySqlConnection connection = new MySqlConnection(str))
            {
                connection.Open();
                DateTime now = DateTime.Now;
                using (MySqlCommand cmd = new MySqlCommand("SELECT * FROM Transactions;", connection))
                using (MySqlDataReader reader = cmd.ExecuteReader())
                    while (reader.Read())
                        ids.Add(reader.GetUInt32("ID"));
                Console.WriteLine("Loaded " + ids.Count + " items. App working time = " + (DateTime.Now - now).TotalSeconds + " sec");
            }

Any ideas how to explain this situation?

Answer 1

Compare the connection in both tests that they create there by default, plus check only in the release. Well, yes, the official one is more slow and has fewer features in the field of integration with EF

Answer 2

The question applies primarily to .net developers!

Then the tags should be appropriate.

Recently, when translating a project from .net core 3.1 to 5.0, I decided to switch from Pomelo.EntityFrameworkCore.MySql to the official MySQL connector (MySql.Data.MySqlClient) and came across a sharp drop in application performance.

And there is. The Oracle driver is terrible.
PS: benchmarks are better done with BenchmarkDotnet (rather than Stopwatch or DateTime) - it is smarter and warms up the code before the measurements so that the JIT has time to compile it.