Search function - lightning fast

[engee30]

Hello Tiku
You could be away and not using the forum as often as you used to, but anyway I wanted to ask a question of you.
I'm working on a lotto project, and I've been trying to find a lightning fast search function, so I could look up in minutes matching numbers and combinations of numbers. I've got some solutions, but they take a lot of time searching the matches.
Let me show you what I've got:

Basically, I'm using InStrB in my search function, but like I said it takes too much time.
For i = 0 to 14000
If InStrB(LB(i), "24") And InStrB(LB(i), "49") Then 'looking for a matching pair of 24 & 49 in a draw
iPair = iPair + 1
End If
Next
Do you happen to know of a better solution speed-wise? Or maybe a similar function is already implemented in the ExplorerListView, possibly under FindVirtualItem sub. I would really appreciate it if you could share your knowledge on this subject.
Kind regards,
engee30

[TiKu]

Well, the first optimization would be to use separate If statements, since VB6 does not know short-circuiting and will execute both InStrB functions even if the first one already returned False. So this should already be a lot faster:

Code: Select all

If InStrB(LB(i), "24") Then
  If InStrB(LB(i), "49") Then
    ...
  End If
End If

[engee30]

Hello Tiku
Thanks for your suggestion. And yes, it did the trick to some extent.
Do you happen to know of any function that would involve CopyMemory? I've heard the function can deal with lots of data with a great performance rating, but never found any dealing with lotto-like searching functionality.
And I'm still intrigued with that FindVirtualItem sub in your ExplorerListView? Would that be of any use in my scenario, do you think?
engee30

[TiKu]

CopyMemory is for copying raw data in memory. I cannot imagine how this would help in this scenario.
A virtual list view does not store any information about the items itself. Instead it raises an event whenever it needs such data and the application is responsible to deliver the data. This way it is possible to deal with a large amount of data, because something like windowing (to speak in SQL terms) becomes possible, i.e. you can have millions of items on disk or somewhere else and only a small range of items in memory. So in the end the speed of a virtual list view relies completely on the client application using it. If it is slow on delivering the required data, the list view will also be slow.
So I think a virtual list view would not help.

Maybe keeping the data to be searched in a hash map (dictionary) would help, but I don't know whether the architecture of your software would allow using a hash map without just shifting the performance issues to another part. The Collection class of VB6 is a hash map implementation. It is not a very fast one, but with a bit of googling it should be possible to find faster ones.

[engee30]

Thanks again, Tiku. As I said earlier, with regards to the CopyMemory function, I couldn't find any solution that would suffice in my situation. And your answer says it all - it's not supposed to be used for that particular scenario.
I do remember reading something about the VB6 Collection class, so I think I'll have a thorough look on the Net for it and see what I could achieve with that.
I'm remembering now a similar conversation we had on this very forum about a virtual listview, and I can honestly say that it DOES work with your ExplorerListView perfectly. I'm talking about my other lotto app, in which I used more than 300,000 items that had to be stored on the disk, but accessed through the data in the virtual listview mode. It was like coming out of the Stone Age into the Bronze Age, or even the Iron One. I can remember waiting for long periods of time for the data to get loaded into the regular listview (prior to virtualization), but then it was just a matter of seconds with the virtual one. Great job you did then with your help. Sadly, the program was no use at later stages, which made me suspend work on it.
Thank you Tiku for your time and help as ever.
engee30