Turning down user expectations.


    After some indications from a faithful (thanks Bill) user I found a perceived ‘hang’ in logview4net; If you load two large files (>500 lines) it will hide the progress bar for the second file. I have fixed that so now it doesn’t appear to hang while loading the files. It is still unusable until both files are loaded though.

    I have to implement some kind of auto sizing of the buffer and then I’ll do a new release. Probably within a week.

    The bigger performance issue is a little harder ;)

    I have users that monitor the Windows Event Log and some log files on >50 servers and keep the app running all the time. If I stored all that data their workstations would be out of memory most of the time. So the conflict is between the style of usage where you want to see all data, as in loading a large file, and their style of usage where there is an infinite amount of data. The current solution is to load the large files into memory and just treat it as a large buffer, but it is painfully slow. I would rather just load the data needed on the screen at the moment.

    I will keep on tuning it, but implementing a sliding window is almost a new application so it will probably not happen soon. I will keep large file loading in mind though so that it wont get worse. It is the multitude of listeners and the possibility to have more than one listener in a session that makes this hard to solve.

    I have previously made the decision to evolve logview4net as a real time log monitor and not a log file parser so I will prioritize new listeners and actions before large file parsing performance.

    The application that inspired me to make logview4net is Chainsaw. If logview4net doesn’t fulfill your needs maybe Chainsaw will. I didn’t want to install a Java runtime just to listen to a UDP port so I started writing my own app instead.