It's a top-down, forward-only, event driven way of reading large XML documents. The point is that performance is almost everything in business apps these days. The world is too hell-bent on XML and tries to solve all its problems with it and most people like my boss who wanted us to replace an entire, very large database with XML - and lost the battle - really don't know squat about it.
Knowing your technology and the tools to work with it are important. Logging should be fast and generating reports should be secondary to the primary function of your application, so an extra step to produce XML is appropriate in lieu of hampering your performance.
Actually, there is one corolarry to this: if you're using a logger to output XML as text, there's not much wrong with this, but using serialization or the DOM to do so is crazy. Again, this is why SAX was developed, so that the entire tree didn't have to be read. Hello again, You are right about the memory requirements and DOM. Nevertheless, thank you for all your remarks. Whoa whoa whoa, hold on there. I've been researching and developing with XML since it was still a wet-dream to most people.
I truly believe in XML and have done a lot of work with it. But a good advocate knows when his or her subject isn't the best solution. XML is great for may things and does solve many problems, but it doesn't solve all of them.
Platform-agnostic solutions are difficult at best without a standard capable of expansion like XML. Only a couple years ago this was a very difficult thing to accomplish and always involved having to develop such documents or applications with little help from frameworks.
However, it still doesn't work for everything. Take, for example, the current solution I architected for work that relies on remoting on a system that must be extremely scalable since it's an Internet-based Windows Forms application with a remote DB. With remoting even exposed as a Web Service for firewall'd clients we can either use a SOAP formatter or binary formatter. With SOAP, a DOM must be created in memory to serialize data correctly, then transfered across the wire in a Unicode format so 2 bytes per character, already twice the size to transfer , then reconstructed so the server can deserialize using the DOM.
A lot of memory, CPU time, and throughput are wasted. If we use a binary formatter, the size is consistent and serialization is much faster since a DOM is not used on either side.
There are many other examples where XML may not be the right choice. That's the only point I'm trying to make here. If you are just writing XML as text, so be it. I was just warning about the implications of using the DOM because - as I said before - logging must be faster and having a potentially large tree in memory most of which is probably in the pagefile that must be parsed just to add a new "record". Back, If I had to develop the same kind of app over the Internet, I would do something similar I think.
I totally agree with you and your binary approach is the best solution to handle the bandwith, size and speed issues of transfers over the Internet. Did you try to add some compression in the process, if it is possible? You made your point about the use of XML and I'm also convinced it is not the best solution for everything. I believe our views are just a little bit different for this particular logging case. Bye, R.
We'll implement simple RLE compression for this first version and implement something closer to zlib later. Basically, we have to override the formatter sink and just run the bytes through a compressor. There are several compression libraries out there, but since one needs to sit on the client, I don't want throughput wasted by excessive functionality we don't need.
We just need the compression algorithm, not file support, stream support, MIME encoded base64 support, etc. By simply overriding the binary formatter, we can hypothetically call the base classes primary methods then just run the return through an algorithm.
Yes, It sounds very good. Your project looks very interresting indeed. No I didn't. It's a nice site and made its way into my bookmarks. It's nice to look through the documentation of the algorithms and not have to pour through tons of code.
Hello, Yes logging must be fast, but it also depends on the amount of informations you log. If you log not so often, the logging process will not be an issue. Yes this particular solution very basic indeed is not running on a separate thread and may raise some concerns, but multi-threading, just like XML is not always the best solution.
Sometimes keeping the number of threads low helps helps saving some CPU cycles wasted by thread synchronisation and other mechanisms. When logging or whatsoever in a thread, it is the job of the programmer to avoid a long blocking operation. Speaking about performance, it is everything in the business, but it depends of what kind of app you are developing. Performance is a more bigger subject than just XML. Ok you can save CPU cycles with a efficient homemade logging system, but maybe you waste somewhere else because you believe you should use this specific utility class or library.
I agree with you about the stupid idea of using XML instead of a very large database. It makes very much sense. It is one example of being reasonable. Close sequence. It ensures that the Dispose method internal method used by the Open XML SDK to clean up resources is automatically called when the closing brace is reached.
The block that follows the using statement establishes a scope for the object that is created or named in the using statement, in this case mySpreadsheet. The basic document structure of a SpreadsheetML document consists of the Sheets and Sheet elements, which reference the worksheets in the Workbook. A separate XML file is created for each Worksheet.
SheetData represents the cell table and contains one or more Row elements. A row contains one or more Cell elements. Each cell contains a CellValue element that represents the value of the cell. View All. James Upton Updated date Sep 30, Exception except for the following: System. AppDomainUnloadedException System. BadImageFormatException System. ContextMarshalException System. DuplicateWaitObjectException System.
EntryPointNotFound System. Skip to main content. Find threads, tags, and users My program uses simple LINQ expressions to read from the. Load "myfile. Comment Show 0.
0コメント