.Contains method generate different commands if it take its value from variable or directly

I have a million row in my table when i search in this table by name i use contains method which take its value from variable but the generated command has execution time bigger than the one generated if i pass value directly

if i use variable (3,779ms)

 var value = "test";
            var list1 = source
               .Where(w => w.Name.Contains(value))
               .Take(10)
               .Select((x) => new
               {
                   x.Id
               }).ToList();

• the generated command is
• @__p_1=‘10’
• @__value_0=‘test’

      SELECT TOP(@__p_1) [c].[Id]
      FROM [Categories] AS [c]
      WHERE ([c].[Deleted] IS NULL) AND ((@__value_0 LIKE N'') OR (CHARINDEX(@__value_0, [c].[Name]) > 0))

if i pass value directly (1,080ms)

             var list2 = source
                .Where(w => w.Name.Contains("test"))
                .Take(10)
                .Select((x) => new
                {
                    x.Id
                }).ToList();

• the generated command is
• @__p_0=‘10’

      SELECT TOP(@__p_0) [c].[Id]
      FROM [Categories] AS [c]
      WHERE ([c].[Deleted] IS NULL) AND ([c].[Name] LIKE N'%test%')

EF 6

[roji]

@mo-ah-dawood the code sample you’ve provided doesn’t make any use of Contains. Please open a new issue with a full, runnable code sample and a description of the exact problem you’re running into.

[roji]

EF Core sometimes generates different SQL for parameter and literal/constant cases. In the specific example above, we can use LIKE with a literal because we can detect and escape wildcards (%, _) when compiling the query. The same currently isn’t possible to do efficiently when the pattern is a parameter; client-side parameter transformation would allow using LIKE for this case above - I think #11881 covers that (@smitpatel do you remember if we have a better issue tracking that?).

Although we’ve seen cases where LIKE is significantly faster than CHARINDEX (#7429), this case is surprising because this is Contains rather than StartsWith, and presumably searching in the middle of the string (as above) cannot use an index in any case. So I’m not sure why LIKE would perform so much better than CHARINDEX - I can at least repro this and try to understand a bit better.