Discussion :

[lutecefalco]

Bonjour tout le monde

J'ai voulu faire qqs benchs sur le Sort d'une collection d'objets avec Linq.

Ma class User

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[Serializable]
    public class User
    {
        public long Id { get; private set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string EMail { get; set; }
        public string Login { get; set; }
 
        /// <summary>
        /// Initializes a new instance of the <see cref="T:System.Object"/> class.
        /// </summary>
        public User()
        {
        }
 
        /// <summary>
        /// Initializes a new instance of the <see cref="T:System.Object"/> class.
        /// </summary>
        public User(long id, string firstName, string lastName, string eMail, string login)
        {
            this.Id = id;
            this.FirstName = firstName;
            this.LastName = lastName;
            this.EMail = eMail;
            this.Login = login;
        }
    }

J'ai une méthode qui va taper en base et qui me retourne une List<User>.
La méthode prend en paramètres le nombre de User souhaité.

La méthode pour trier ma liste:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
        private IQueryable<T> Sort<T>(IEnumerable<T> list, string sortExpression)
        {
            return list.AsQueryable().OrderBy(sortExpression + " ASC");
        }

Pour mon bench, j'ai exécuté 100 fois la méthode Sort à 3 reprises:
1 fois sur une collection de 50 Users
1 fois sur une collection de 500 Users
1 fois sur une collection de 5000 Users

Et à chaque fois, j'obtiens le même résultat (14 ms pour 100 itérations)

Qq'un a une explication?

Merci

[cybermaxs]

Salut,

as tu essayé de faire varier encore le nombre de User ?
Le tri n'est pas forcément couteux avec ce nombre. J'ai essayé ton code, avec 50 000, j'ai vu des différences.
Autre point, avec l'exécution différée des requêtes, as tu "consommé" le type en retour ou pas ?

[lutecefalco]

Salut,

as tu essayé de faire varier encore le nombre de User ?
Le tri n'est pas forcément couteux avec ce nombre. J'ai essayé ton code, avec 50 000, j'ai vu des différences.
Autre point, avec l'exécution différée des requêtes, as tu "consommé" le type en retour ou pas ?

J'ai que 6 000 users en base donc j'ai pas essayé plus
Sinon, non je consomme pas le retour, j'appelle juste 100 fois ma méthode Sort

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
sw.Start();
            for (int i = 0; i < iterations; i++)
            {
                Sort(list, "LastName");
            }
            sw.Stop();
            elapsedDR = sw.ElapsedMilliseconds;
            sw.Reset();

[cybermaxs]

Sinon, non je consomme pas le retour, j'appelle juste 100 fois ma méthode Sort

Les requêtes LINQ sont à exécution différée, ce qui signifie que les requêtes ne sont réellement faites que lorsque le code en a besoin, donc en gros quand on utilise le retour de la requête. Le Sort n'est pas donc réellement réalisé dans ton cas : c'est juste l'arbre des expressions qui est construit.

Une méthode simple et peu couteuse est de faire un Count ou un ToList()

[lutecefalco]

En effet, une fois le Count appelé, la performance s'en ressent.
Mais du coup je compte l'appel à .Count dans mon bench...

J'ai aussi regardé du côté des requêtes compilées mais j'ai l'impression que ça existe que pour du LinqToSql

[cybermaxs]

En effet, une fois le Count appelé, la performance s'en ressent.
Mais du coup je compte l'appel à .Count dans mon bench...

Je pense pas que le Count pèse cher dans la balance. Peut être un .First() est il plus léger.

J'ai aussi regardé du côté des requêtes compilées mais j'ai l'impression que ça existe que pour du LinqToSql

Oui c'est que pour LinqToSql, mais attention c'est pareil : l'arbre d'expression Linq est juste calculé un peu plus en amont.