On 8/27/14 2:59 PM, Jonas Sicking wrote:
On Wed, Aug 27, 2014 at 12:14 PM, Eric Rahm <er...@mozilla.com> wrote:
* console.log is a more standard solution but is "slow":
I'm not sure how much this matters, it depends what slow means. Does
it take a while for the log to show up, does it cost a lot of CPU
(even when not being viewed), does it actually have a lot of overhead
for the calling application?
I don't understand why one logging function would need to be slower
than another logging function. I.e. why would
console.log("displaying frobber");
need to be any slower than
newFangledLog("displaying frobber");
or
dump("displaying frobber");
The fact that console.log is slow right now is probably due to how we
have implemented it, not due to the way the API is designed. It seems
preferable to me to change the implementation of console.log rather
than write a new implementation of a new logging function.
The only reason I could see why console.log is slower is if there's so
many existing callsites of console.log that if we make it actually log
the way we want to log, that we'd end up logging so much information
that that would be a problem. But it doesn't sound like that is the
concern that people have with console.log.
So, in short, I think we should look at making console.log faster
rather than introducing a new API.
/ Jonas
I agree, using console.log and friends makes sense. I'm not really sure
I follow the "it's slower" argument (I was just restating it). Slowness
of logging -- I assume that means amount of time from writing a log
entry to displaying it -- just really shouldn't matter. Sure it would be
good to fix, but it shouldn't prevent us from using console logging.
It just depends what slower means, it might mean "lots of overhead" or
"literally my application is blocked for N ms while trying to log," that
needs to be determined.
As Dave Hylands pointed out, all console.* functions currently get
proxied to the main process. So there's IPC and memory overhead that can
have a serious impact. Now that is a legitimate reason not to use
console logging.
We can avoid that if we add some way to prevent console logging from
being proxied if that application's log is disabled, or if the log level
isn't high enough. Currently I don't think that's possible (I may be
wrong about this), so we'd need to modify the console logging
functionality. In a more extreme case on b2g we could just not proxy the
logs at all and basically do a dump() but with prettier formatting.
Further functionality we would need to add is pumping out the console
log to logcat on b2g devices (and presumably adding a proper component
name).
-e
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
