Article Links?
-
My Google-fu is not working - I keep ending up with maths links! Does anyone have any links to articles / resources detailing the time overhead of logging to file? I've added logging to my undo functions to give a rough session activity trace and my boss is concerned about the time overhead wrt file access (I open, append, and flush every message). Before I start timing things, can anyone speak about this from experience?
-
My Google-fu is not working - I keep ending up with maths links! Does anyone have any links to articles / resources detailing the time overhead of logging to file? I've added logging to my undo functions to give a rough session activity trace and my boss is concerned about the time overhead wrt file access (I open, append, and flush every message). Before I start timing things, can anyone speak about this from experience?
-
My Google-fu is not working - I keep ending up with maths links! Does anyone have any links to articles / resources detailing the time overhead of logging to file? I've added logging to my undo functions to give a rough session activity trace and my boss is concerned about the time overhead wrt file access (I open, append, and flush every message). Before I start timing things, can anyone speak about this from experience?
A little CodeProject-fu can go a long way: [^]. That's only one of a number of excellent articles on CP relevant to precision Timeing in .NET. You should use the StopWatch Class, not a Timer. good luck, Bill
"What Turing gave us for the first time (and without Turing you just couldn't do any of this) is he gave us a way of thinking about and taking seriously and thinking in a disciplined way about phenomena that have, as I like to say, trillions of moving parts. Until the late 20th century, nobody knew how to take seriously a machine with a trillion moving parts. It's just mind-boggling." Daniel C. Dennett
-
My Google-fu is not working - I keep ending up with maths links! Does anyone have any links to articles / resources detailing the time overhead of logging to file? I've added logging to my undo functions to give a rough session activity trace and my boss is concerned about the time overhead wrt file access (I open, append, and flush every message). Before I start timing things, can anyone speak about this from experience?
If you're really concerned about the impact of logging to a file you can do the logging in a seperate thread dedicated to that functionality. This may be a bit more resource intensive than directly writing to the file but also reduces the cost on the main execution thread.
-
My Google-fu is not working - I keep ending up with maths links! Does anyone have any links to articles / resources detailing the time overhead of logging to file? I've added logging to my undo functions to give a rough session activity trace and my boss is concerned about the time overhead wrt file access (I open, append, and flush every message). Before I start timing things, can anyone speak about this from experience?
This is one of the reasons I would look for external sources for logging, rather than rolling my own version. There are any number of excellent logging systems, and I would have looked to use one of these instead. Saying that, there are several things that you can do to alleviate issues - log in the background, don't write to file on every log (build a buffer which you periodically flush to disk), investigate alternatives to writing to file.
-
This is one of the reasons I would look for external sources for logging, rather than rolling my own version. There are any number of excellent logging systems, and I would have looked to use one of these instead. Saying that, there are several things that you can do to alleviate issues - log in the background, don't write to file on every log (build a buffer which you periodically flush to disk), investigate alternatives to writing to file.
This is essentially a debugging tool, since our users are rubbish at describing what they were doing when a problem / crash happened (aren't they all?). I started off logging to memory, then dumping the session log and call stack in my "crash-catcher". But then I was concerned about memory usage and likelihood-of-failure at the crucial moment, and obviously then my log wouldn't be available in non-crash situations. Since it is a CAD program and logging actions happen only a little more frequently than you can do things with a mouse, I don't think the overhead will be significant - but I'll probably have to do some timings to prove it to my boss! I'll also chuck in a settings switch to turn logging off if necessary, that should keep everyone happy :)