RE: StaticHierarchy class?
Yoav - Do you have some numbers to share for this? I'd love to tell my bosses Ceki and Yoav said so., but I don't think they'd buy it without some hard numbers ;) thanks scott -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 1:20 PM To: Log4J Users List Subject: RE: StaticHierarchy class? Howdy, Why is saving memory not important? Saving memory is important. However, like Ceki said (I've verified this using a profiler for our system), the Logger instances (even at 1 for each class) take so much less memory than your application classes, that their memory footprint is insignificant. And ultimately, IMHO memory is cheap and performance (speed) matters more than memory. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: StaticHierarchy class?
Scott, You can use a profiler tool to get a picture of what the memory usage is for log4j related objects. Something like OptimizeIt will do the trick if you have it, or even the built-in profiler. I have to echo Yoav and Ceki on this. I looked at this in our servlet container, and compared to everything else that is created, the log4j objects are miniscule. That may not be true in all environments as I imagine that in an embedded system environment any and all memory usage would be suspect (you aren't doing an embedded system are you?). But once most of your system is up and initialized, the percentage given to log4j objects is very low, as you will see in the profiler data. I think it also useful to point out that once you have most of your system up, the log4j objects will not greatly contribute to forcing/incurring garbage collections (another performance concern related to memory) as almost all the logger objects will have already been created and static in memory. String creation for logged messages will create memory, but any system you choose will most likely incur this as well. -Mark -Original Message- From: Klein, Scott @ TW [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 7:57 AM To: 'Log4J Users List' Subject: RE: StaticHierarchy class? Yoav - Do you have some numbers to share for this? I'd love to tell my bosses Ceki and Yoav said so., but I don't think they'd buy it without some hard numbers ;) thanks scott -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 1:20 PM To: Log4J Users List Subject: RE: StaticHierarchy class? Howdy, Why is saving memory not important? Saving memory is important. However, like Ceki said (I've verified this using a profiler for our system), the Logger instances (even at 1 for each class) take so much less memory than your application classes, that their memory footprint is insignificant. And ultimately, IMHO memory is cheap and performance (speed) matters more than memory. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: StaticHierarchy class?
Logger x1 = Logger.getLogger(x); Logger x2 = Logger.getLogger(x); Both x1 and x2 reference the exact same object. Of course, but you lose the class level granularity for configurations. Which is exactly what I would like to keep, and in order to do so you must create loggers by class. The issue is that if you have a configuration for com.foo, then request a logger with the class com.foo.bar.FooBar a new logger instance is created, rather than using the com.foo logger. (just as a side note: the interesting thing here is that it will have a configuration like com.foo). Even if the saving in the memory footprint were important (which they are not!) Why is saving memory not important? Can you give me some insight into how you would configure a system that needs to be able to have each classes logger configurable while also being able to keep the total number of loggers instantiated well below n, where n is the total number of classes loaded in the system (and using Loggers). thanks scott -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 12:40 PM To: Log4J Users List Subject: Re: StaticHierarchy class? At 14:46 19.06.2002 -0700, Klein, Scott @ TW wrote: I'm full of questions/comments today... Has anyone worried about the amount of resources (primarily mem space) attributed to Log4J to the extent that there was a need for a StaticHierarchy whereby, if a user requests a Logger that does not exist it will NOT be created. Basically, they have to be listed in the config file. A little strict - but I was thinking a step further where if com.foo.bar.FooBar asks for a Logger using getLogger( this.getClass() ) then a non-Null (or non-Root!) logger is returned iff: + there is a predefined logger for com.foo.bar.FooBar OR + there is a predefined logger for com, or com.foo, or com.foo.bar - but in this case the logger returned is NOT a newly instantiated one, but the corresponding logger to the match as if they had called getLogger( com.foo ) for example (if that makes sense). Logger x1 = Logger.getLogger(x); Logger x2 = Logger.getLogger(x); Both x1 and x2 reference the exact same object. Basically, the constraint is that if the class does not have a logger defined for it, or the class is contained in a package that does not have a logger defined for it, or its super-packages, then the root logger is returned. Otherwise, the deepest logger in the hierarchy along the path to the requestor is returned. You lose flexibility (you can't have people making changes to the Logger they get), but you save resources. Not sure if all that makes sense, but my primary concern is if I have 100 classes that ask: Logger.getLogger(this.getClass()) then I am going to be carrying 100 instances of Logger around (guaranteed). Even if all your 100 classes used the root logger the gains in the memory footprint would be negligible compared to the memory foot print of your 100 classes. Even if the saving in the memory footprint were important (which they are not!) the list of configured loggers can change during the execution of the program but an already assigned logger cannot shed its skin and automatically assume another identity. Any thoughts or comments on if/why/how this might accomplished? Yes, one comment: don't tune what you don't need to tune. Here is one of my favorite quotes: Have lots of ideas and throw away the bad ones. You aren't going to have good ideas unless you have lots of ideas and some sort of principle of selection. -- Linus Pauling (the only person to win two unshared Nobel Prizes) thanks s -- Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: StaticHierarchy class?
At 13:04 21.06.2002 -0700, you wrote: Even if the saving in the memory footprint were important (which they are not!) Why is saving memory not important? I did not say saving memory was not important! I mistyped savings as saving which apparently changed the meaning of the sentence. What I had meant to write was: Even if the savings (as in economy, a reduction in expentidute) from in the memory footprint were important (which they are not!)... What I mean is that the gains that you will acheive (at the cost of a lot of work) are guaranteed to be negligible. Can you give me some insight into how you would configure a system that needs to be able to have each classes logger configurable while also being able to keep the total number of loggers instantiated well below n, where n is the total number of classes loaded in the system (and using Loggers). Interesting problem formulation. IMHO, I think it can be solved in a complicated and convoluted way which unfortunately I do not have the time nor the will to expose here. Moreover, solving it would not bring any substantial gains. Again, don't tune what you don't need to tune. thanks scott -- Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: StaticHierarchy class?
Howdy, Why is saving memory not important? Saving memory is important. However, like Ceki said (I've verified this using a profiler for our system), the Logger instances (even at 1 for each class) take so much less memory than your application classes, that their memory footprint is insignificant. And ultimately, IMHO memory is cheap and performance (speed) matters more than memory. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
