On Wed, Aug 27, 2014 at 4:45 PM, Eric Rahm <[email protected]> wrote: > 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.
I got the impression that the problem was "application is blocked for N ms", which seems like a fixable implementation bug. > 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. I don't think sending the data to the parent process is a problem. As long as we don't synchronously block while that IPC is happening. Simply sending the data asynchronously and then immediately return to the calling JS should mean that the IPC is causing no problem. If we want to do anything useful with the data it most likely needs to go to the parent process anyway. Child processes never have permission to directly write to files, and of course any UI that lives outside of the application is handled by other processes, which means that it has to at least go through the main process. > 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. Doesn't dump() also send the data to the parent process eventually? / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
