Re: [riena-dev] Cache for LOGGER.isLoggable

["Campo, Christian" <Christian.Campo@xxxxxxxxxxxx>]

Hi Patrick,

I think its is potentially dangerous to cache results of isLoggable because the result of this method could potentially change. i.e. you add a logger at runtime that prints debug messages.
- How would you flush the cache at runtime ?
- When would the result be cached, after the first call when more loggers can still be added, that change the result of isLoggable ?
- Did you measure how much impact the fact has that it is no cached ?
- Did you think of wrapping the call to Log4r.getLogger() yourself and built a cache there if you think its important for your own code ?

In my past experience with caches, I always experienced that caches are only a last resort and they create more problems than they solve. So at the end having the result of isLoggable cache MUST result in an overall speed improvement of say 10 % of more in your overall application speed to be a good thing. (others would argure that it has to be more) Dont you think ?

Maybe its easier once we understand how much speed improvements you are hoping for.......

- christian

Am 16.07.2010 um 07:12 schrieb Patrick:

> Hi Elias and reina-dev,
>
> Thanks for the thoughts.
>
> It looks like Log4r.getLogger() returns an instance of
> org.eclipse.equinox.log.internal.LoggerImpl , which delegates an instance of
> org.eclipse.equinox.log.internal.ExtendedLogServiceImpl . and eventually it
> will be delegated to
> org.eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.isLoggable(
> Bundle, String, int) which does the work.
>
> I personally doubt if it is really equinox's responsibility to cache the
> result of isLoggable() . I think the equinox as the platform is reasonable
> to always get the real-time result, while in most reina application, which
> could usually be either a running hessian service server or a client
> application, would like to have the result cached.
>
> I would recommend to modify the Log4r.getLogger() method so that it will
> return a cacheable instance of org.eclipse.equinox.log.Logger (which is an
> instance anyway). This class will cache result of isLoggable() while
> delegating all other calls to what is now returned by Log4r.getLogger() .
>
> Any thoughts?
>
> Regards,
>
> Patrick He
>
> -----????-----
> ???: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx]
> ?? Elias Volanakis
> ????: Wednesday, 14 July 2010 5:24 AM
> ???: Riena Developers list
> ??: Re: [riena-dev] Cache for LOGGER.isLoggable
>
> Hi Patrick,
>
> thanks for bringing that up.
>
> I'm not the expert in this area (committer Stefan is) but I agree that
> isLoggable(...) should be fast.
>
> However: could you provide some information about where the code that does
> the searching comes from? Are you referring to
> ExtendedLogReaderServiceFactory.isLoggable(...) or something else? In the
> first case: that class is part of the Equinox logging framework so you
> should propably open a bug or talk with them:
>
> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Equinox
> http://eclipse.org/equinox/resources.php
>
> Thanks,
> Elias.
>
>
> On Sat, Jul 10, 2010 at 7:20 PM, Patrick <platinas.hy@xxxxxxxxx> wrote:
>> Hi riena-dev,
>>
>>
>>
>> When we use Log4r.getLogger() to get a logger, there is a method
>> isLoggable(int level). Using debugger to track turns out that it looks
>> like every time this method is called, it consults every registered
>> log listener to ask if this log level is loggable, which looks like is
>> resource consuming if there are many service enquiring if the log level is
> available.
>>
>>
>>
>> The isLoggable method should be a quick one that pre-checks if the log
>> level applies to current environment, as sometimes dumping log data is
>> quite resource consuming and not needed in production mode.
>>
>>
>>
>> Maybe it is good to introduce some cache for the isLoggable method as
>> there are just a few log levels and the result is not likely to change
>> in application execution time.
>>
>>
>>
>> Thanks for any thoughts.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Patrick He
>>
>>
>>
>> _______________________________________________
>> riena-dev mailing list
>> riena-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/riena-dev
>>
>>
>
>
>
> --
> Elias Volanakis | Technical Lead | http://eclipsesource.com
> elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | @evolanakis
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev


-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: http://www.compeople.de/

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
Ust-Ident.-Nr: DE207665352
-------------------------------------------------------------