Its exciting to see LogBook, Comcast Interactive Media’s first open source project get some traction. There is talk of LogBook being included in other open source projects as well as people have started submitting patches and suggestions to the project.
One issue that was submitted a few days back was around the Logging implementation dispatching all logging events out of the application across the LocalConnection. Here is a quote from the issue:
Logging could add significant overhead to an application, due to
log message construction, and sending messages to LogBook.It is good practice to minimize logging overhead, with code like:
if (Log.isInfo()) {
LOG.info(“version: {0}”, version);
}The current implementation of class LocalConnectionTarget always
sets the log level to ALL and the log filter to “*”. This means
that all logging methods are executed, which is undesirable.
You can see the details of the issue here.
I just wanted to elaborate a little on why the LocalConnectionTarget class does not use any kind of filtering to reduce the number of LogMessages being constructed.
One of the reason we went with LogBook as an AIR application as opposed to a web application was because as far as I know, the Flash Player process on the web is independent from that in AIR. This means that LogBook could become a very elaborate application on its own but it will not impact the performance of the application using LogBook based logging. Also when we pass objects across LocalConnection, these objects do not accumulate in the application’s memory. Here is a screenshot from a quick experiment where I ran an endless loop that created a custom LogDispatcher object, had it send a log message across the LocalConnection and then get garbage collected. The memory profile of the application can be seen below:
Here is also the live objects screen capture:
As you can see, over 600 objects were constructed but all of them could be garbage collected with no overhead in terms of memory used.
So your take away from this discussion is: using LogBook has virtually no memory overhead in your application. The idea of broadcasting all messages to LogBook is to allow you to filter the data on the client at the moment of debugging or after, rather than configuring it at some pre-launch time.
Now LogBook itself is another story. Another bug submitted by the same developer who reported this also talked about LogBook’s performance when over 1000 messages were collected, and yes, I have verified that at that point, the application becomes pretty sluggish. So for the next version of the LogBook, I am considering leveraging the SQLite database that AIR comes packaged with.
More on LogBook 2.0 soon. We are already on it and it will be good ;). If you would like to participate in defining the functionality in 2.0 or better yet, help us develop it, join the conversation on the LogBook user group here.
Code Zen 
I can confirm that the AIR app collecting the LocalCollection data can become slow when trying to gather large sets or large amounts of log statements. I haven’t had a chance to look at a better way to handle this is on the AIR side, but there is not easier way around using LocalConnection if you want real time logging.
If you don’t want real time logging you can always batch the data and send it to a remote service and then right an app that will load the remote data service whenever it wants it. I use this approach for collecting of bugs from other people.
LikeLike
@Renaun
Thanks for the update (I accidentally deleted ur other comment on it probably being the UI that may be causing the LogBook to chug a bit), I ‘ll do a memory profiling test on it to see where the bottleneck is.
LikeLike