This looks very interesting.

In memory indexing of collections for faster access: http://www.codeplex.com/i4o http://blog.magenic.com/blogs/aarone/archive/2007/04/09/Introducing-i4o.aspx

Might even be helpful for LLBLGen

All the best, Patrick

I haven't checked it out yet, but indeed, it should be usable with llblgen pro objects right away (as with all Linq to Objects stuff )

Looks interesting, however I don't think I should be very useful regarding to LLBLGenPro as you don't want to load many entities anyway. If you are loading that much entities you have problems

mihies wrote:

Looks interesting, however I don't think I should be very useful regarding to LLBLGenPro as you don't want to load many entities anyway. If you are loading that much entities you have problems

It can still be necessary though to work with large collections e.g. I'm working with a big graph to visualize structures and then having indexed collections can be very helpful...

So I would still like for LLBLGen to provide native support for it

Thanks, Patrick

mihies wrote:

Looks interesting, however I don't think I should be very useful regarding to LLBLGenPro as you don't want to load many entities anyway. If you are loading that much entities you have problems

Even if your collection is quite small it can be useful, 10ms instead of 100ms might look like it's no big deal but if you have to repeat the searching process 200-4000 times, it's a huge gain. We had to provide in-memory editing of very big orders (many thousands products) in our application. When editing an order, End-users don't add products one at a time, they use custom tools and formulas to select large ranges of products. For each product in the selection we have to check if it already exists in the order with the specified size and color attributes, in case it's already there, we increase the quantity, in case it's not there, we add it. Doing so without indexing is just too inefficient.