I have been playing around with XLinq in C# 3.0, and I must say I am not that fulfilled by the querying aspects of the API.
I must say this right now, I have not explored its potential fully, and I am definatly not an expert on the subject but I was hoping for something more. For instance, my biggest gripe at the moment is that it has an "in-memory" query language (unless I am mistaken) which means that the XML document has to be fully loaded into memory.I don't have the code I was using in hand at the moment, but I wanted to load a 900MB XML file to do some simple processing on it. I had the code ready to itterate accross the XML document and do a simple select on the data fields that I wanted and it would return a List<> of the correct objects (this part seemed cool). I ran out of memory though :( I did the same thing with a normal XML Reader in just the same time it took me to create the SELECT statement (admitadly I had to learn about XLinq) and it was soooooo much quicker and the memory footprint was a lot smaller. It just struck me that using XLinq was an overkill, it didn't offer me anything extra for this simple task and it had to load the whole document into memory. I would like to see an XLinq that didn't have to load the whole document but could SAX push or XmlReader pull the data as it scanned through the document. I am pretty sure (after I thought about it) that this would be achieve able quite easily on Microsofts part, because I presume (and I am only presuming) that the XLinq has to forward scan and depth traverse through the DOM that it would be like scanning through the document with an XMLReader, after all the way the .Select arguments are ordered is pretty intuative to that sort of scanning. Other operations such as grouping could be done one the array of filtered objects has been brought back. This way he document would not have to be completly loaded into memory first and only a subset of the data would be loaded.Maybe XLinq can do this already. I am definatly not seeing how, but I know I can miss things. It just seems that it will be okay at the small things, but after a certain size document it loses its appeal.
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.
I love to learn about what you are building, and how I can help with Chrome or Web development in general, so if you want to chat with me directly, please feel free to book a consultation.
I'm trialing a newsletter, you can subscribe below (thank you!)
