The way the app is reading and parsing XML files can be a problem with very big files (500 MB ! that's a log !).
Some improvements can be done, surely. But this is not possible to write something in the original files. The app must deal with files that have their own life cycle. For example, I often use the app to read a log file while it is used by its own app that
can still write lines. This is why there is a "refresh" function : to reload files that have changed since they have been loaded.
Writing some header/footer to a log can break any addition to it. So this is not a valid solution. The app must add what is needed without modifying the original files.
One can thing then about a cache folder where modified files are stored along with a CRC, if the user reopens the same file and CRC has not changed, then the cache copy is opened instead of the original. If the file has changed then it is modified and stored
in the cache folder.
This can be a solution, even though the cache can become very big... (mainly with 500 MB logs !). But this can help with most middle size logs. (small logs are not a problem).
The part that is parsing the xml files should be isolated in a Task to let the UI be reactive. A progression bar will then be something cool.
I also think we can work on a way to parse the file using paralell Linq. This can greatly shorten file loading on most computers (mine has 8 cores, but it is very common to see 2 or 4 cores).
Now, the file size can be a problem. The example of 500MB log is not a "normal condition" for the application at this time. The question is "must we do something to allow such big files, if yes, what, and if not, how to prevent crashes ? (adding a test on
file size before parsing ? looking at free memory ? ...).
what do you think about these problems?