The log-viewer application is available as source code in the "Samples" folder, in the "11 - Exception logging" sub-folder.
Open log files
You can run it with a specified log file on the command line, or use the
"Open" button to browse for a file. That is, you can associate this
tool with your
.log files, for instance, and you'll open it just
by double-clicking on such files.
Note that if the file is not in our
TSynLog format, it will
still be opened as plain text. You'll be able to browse its content and search
within, but all the nice features of our logging won't be available, of
It's worth saying that the viewer is fast.
In fact, it takes no time to open any log file. For instance, a 280 MB log file is opened in less than one second on my laptop. Under Windows Seven, it takes more time to display the "Open file" dialog window than reading and indexing the 280 MB content.
It uses internally memory mapped files and optimized data structures to access to the data.
The screen is divided into three main spaces:
- On the left side, the panel of commands;
- On the right side, the log events list;
- On the middle, an optional list of method calls (not shown by default).
The command panel allows to Open a
.log file, see the
global Stats about its content (customer-side hardware and software
running configuration, general numbers about the log), and even ask for a
source code line number and unit name from an hexadecimal address available in
the log, by browsing for the corresponding
.map file (could be
handy if you did not deliver the
.map content within your main
executable - which you should have to, IMHO).
Just below the "Open" button, there is an edit field available,
with a ? button. Enter any text within this edit field, and it will be searched
within the log events list. Search is case-insensitive, and was designed to be
fast. Clicking on the ? button (or pressing the
F3 key) allows to
repeat the last search.
In the very same left panel, you can see all existing events, with its own
color and an associated check-box. Note that only events really encountered in
.log file appear in this list, so its content will change
between log files. By selecting / un-selecting a check-box, the corresponding
events will be instantaneously displayed / or not on the right side list of
events. You can click on the Filter button (or right click on the
events check-box list) to select a predefined set of events.
The right colored event list follows the events appended to the log, by time order. When you click on an event, its full line content is displayed at the bottom on the screen, in a memo.
Having all SQL and Client-Server events traced in the log is definitively a huge benefit for customer support and bug tracking.
One distinctive feature of the
TSynLog logging class is that it
is able to map methods or functions entering/leaving (using the
Enter method), and trace this into the logs. The corresponding
timing is also written within the "Leave" event, and allows
application profiling from the customer side. Most of the time, profiling an
application is done during the testing, with a test environment and database.
But this is not, and will never reproduce the exact nature of the customer use:
for instance, hardware is not the same (network, memory, CPU), nor the software
(Operating System version, [anti-]virus installed)... By enabling customer-side
method profiling, the log will contain all relevant information. Those events
are named "Enter" / "Leave" in the command panel check-box
list, and in the right-sided event list.
The "Methods profiler" options allow to display the middle optional method calls list. Several sort order are available: by name (alphabetical sort), by occurrence (in running order, i.e. in the same order than in the event log), by time (the full time corresponding to this method, i.e. the time written within the "Leave" event), and by proper time (i.e. excluding all time spent in the nested methods).
The "Merge method calls" check-box allows to regroup all identical method calls, according to their name. In fact, most methods are not called once, but multiple time. And this is the accumulated time spent in the method which is the main argument for code profiling.
I'm quite sure that the first time you'll use this profiling feature on a huge existing application, you'll find out some bottlenecks you would have never thought about before - it's what happened to me
Comments and feedback are welcome on our forum, just as usual!