[RESOLVED] How convert this code listview.Items.Remove to linq help Paul ?

[Andres128]

Hi great community again

I have this problem with my code, is very slow and I learn linq is ver fast for parse data

I have this code:

                Dim min, max As Integer

                 min = 10
                 max = 20

                For Each lvi As ListViewItem In ListadoView.Items

                   If Not lvi.SubItems(1).Text >= min Or Not lvi.SubItems(1).Text <= max Then
                        
                    ListadoView.Items.Remove(lvi)

                    End If
                Next

How I can I convert this previous code to linq be faster, it is currently very slow

Thank you very mucho to the people who take the time to help me, really thank you. Many greetings to all.

And thanks for visiting my post .

[ident]

LINQ is not faster. All LINQ under the hood is a for statement so how can it be faster? In fact is alot slower.

LINQ should ne used to make code more readable. In fact in this case it does the opposite.

Public Class Form1
 
    Private Sub RemoveListViewItems()
        Dim min, max As Integer
 
        min = 10
        max = 20
 
        Dim query = Me.ListView1.Items.Cast(Of ListViewItem)().Where(Function(lvi) Not lvi.SubItems(1).Text >= min OrElse lvi.SubItems(1).Text <= max)
 
 
        Array.ForEach(query.ToArray, Sub(lvi)
                                         Me.ListView1.Items.Remove(lvi)
                                     End Sub)
 
    End Sub
 
End Class

[Toph]

LINQ is not faster. All LINQ under the hood is a for statement so how can it be faster? In fact is alot slower.

I think that's weird how a Linq foreach on a 1D array is slower than a regular for each on a 1D array. Afterall, both statements are O(n) operations, therefore theoretically both should take the same time.

[techgnome]

IT really depends on how it's constructed... I've actually found a couple cases where LINQ was faster... I think it was due in part to the delayed execution, so it doesn't run the query immediately, but on demand, when I access the results.

That said, I don't think LINQ will be a lot of use, nor is the original code... I'm surprised you're not seeing odd results. If you are on Row 2, and you remove it, what was row 3 becomes row 2, so when you iterate to the next item, you get the new row 3, which is the old 4, actually I'm surprised you're not getting an error about editing the collection while iterating through it.

-tg

[ident]

IT really depends on how it's constructed... I've actually found a couple cases where LINQ was faster... I think it was due in part to the delayed execution, so it doesn't run the query immediately, but on demand, when I access the results.

-tg

can you show the example? Thats generally interesting on non immediate querys as the line does nothing. there are some linq methods that do sort querys quicker. But sorting is not a for each loop. Which is what the question was asked. interested TG buddy.

[passel]

I don't know what your Listview items look like, or how many you have, but a quick test I just did (which hopefully is valid), would seem to indicate the bottleneck is the multiple removing of items from the list.

So instead of deciding which items to remove, I thought about doing the reverse and decide what items to keep, adding them to a list.
Then, clear the listview, and add the saved items back in one fell swoop.

In my brief test which added a 1000 items to the list, with a random subitem value which ended up removing about 700 of the items from the list, took about 1.4 seconds.

Changing to clearing the list and adding back the 300 kept items took about 42ms, so was a little over 30 times faster.
Perhaps, assuming the premise is valid, it will speed up your situation.

    Dim min, max As Integer

    min = 10
    max = 20

    Dim KeepList As New List(Of ListViewItem)

    For Each lvi As ListViewItem In ListadoView.Items
      If lvi.SubItems(1).Text > min And lvi.SubItems(1).Text < max Then
        KeepList.Add(lvi)
      End If
    Next

    ListadoView.Items.Clear()
    ListadoView.Items.AddRange(KeepList.ToArray)

[ident]

Good thinking passel. How ever as you have already shown above

To add a set of items to the control in a single operation, use the AddRange method.

[.paul.]

I don't know if this has been mentioned, but the problem with repeatedly calling .Remove is that the listview is repainted after each .Remove call.

Passel's solution is the best way i know of...

[ident]

I don't know if this has been mentioned, but the problem with repeatedly calling .Remove is that the listview is repainted after each .Remove call.

Passel's solution is the best way i know of...

Since we dont want deferred execution would findall be better suited?

[Andres128]

@Ident, thank you for all your help mate, I am new with LINQ and i thought it was fast, then I was wrong i will learn more of the LINQ, thanks for everything and greetings.

@Toph, thank you for visiting my post

@techgnome, excellent explanation bro, thanks

@passel, impressive response friend, thank you very much in addition to being a code pretty fast, explain it very well, thank you very much for helping me, I resolved my question

@.Paul., You are one of the best with LINQ, thousand thanks for your response!

Without more brothers, i have been with the response of the friend @passel in truth is a very fast code, but I also liked the the friend @ident, thank you all for your time and dedication in my post ... I have solved my problem, salutations to all and that you have a great day.

Att: Andres128

[.paul.]

Since we dont want deferred execution would findall be better suited?

What do you mean by deferred execution?

[ident]

What do you mean by deferred execution?

I assume you are joking with me?

[techgnome]

can you show the example? Thats generally interesting on non immediate querys as the line does nothing. there are some linq methods that do sort querys quicker. But sorting is not a for each loop. Which is what the question was asked. interested TG buddy.

Sorry, I don't have an example handy. It was from a previous job where I was tasked with optimizing code...there were several cases where I found some looping going on, which when replaced with a LINQ statement, performance increased. There were also times where I found that the LINQ was the poor performer. I don't think there was much of a rhyme or reason to it. Now that I think about it though, a great deal probably had to do with what the code was doing - looping through ALL of the data, and comparing and only operating on part of the data based on condition. When switching to the LINQ statement, it limits the data being processed, so that the only data used in the loop are the data elements that match the criteria.

What do you mean by deferred execution?

There are some cases where LINQ result produces what's called "Deferred Results" - it can be a tough concept to wrap one's head around because it seems to fly in the face of logic that we're accustomed to.
Consider this:

Dim a as Integer
a= 5

We fully expect that a will contain 5 at the end of the code... it seems logical... it's what we're used to. But let's say that instead of an integer, we assign an object to a, a list that's the result from a LINQ statement...

Dim aList as List(of SomeClass)
aList = SomeObject.where(function (c) c.Property = "A Value")

If SomeObject contains a few thousand items in it, the compiler may decide to delay the actual execution of the query until the first time the list is accessed... at which time it will get the first item in the results... if you're familiar with Recordset from Classic ADO, it's like a server-side cursor, and only fetches rows on demand.There's circumstances that cause this to happen, when it does and you're not aware or expecting it, you can get some really odd functionality - like trying to get counts... I forget what those specific criteria are, but if you look up .NET deferred execution, I'm sure you can find articles the go into it in more detail than I can at the moment.

-tg

[.paul.]

I assume you are joking with me?

    Dim min, max As Integer

    min = 10
    max = 20

    Dim KeepList As New List(Of ListViewItem)

    For Each lvi As ListViewItem In ListadoView.Items
      If lvi.SubItems(1).Text > min And lvi.SubItems(1).Text < max Then
        KeepList.Add(lvi)
      End If
    Next

    ListadoView.Items.Clear()
    ListadoView.Items.AddRange(KeepList.ToArray)

I don't see how deferred execution would be a problem. It's a straightforward loop. It'll run as expected.

[techgnome]

That's not a LINQ query...

It's LINQ statements & lambdas that use deferred execution.

-tg

[.paul.]

That's what i thought, and i still don't see how Ident's comment is relevant...

[techgnome]

I think it was actually in response to my comment initially about deferred execution. It just happened to follow yours.

On a related note - deferred execution isn't necessarily a bad thing, there are ways to deal with it...you just have to know what to do when you run into those situations. Usually it means returning things into a list, rather than directly into the foreach, or you may have to actually create a specific variable rather than using the iterator variable. I've found that the IDE is really good at alerting you to those cases when they crop up.

-tg