Can't you use a regular Java profiler to determine this? Perhaps would be beneficial to start thinking of a generic enough stats module that would reveal information like that to the lift applications. I guess we need to see what the general consensus is and take it from there.
Br's, Marius On May 8, 10:49 am, Oliver Lambert <olambo...@gmail.com> wrote: > On Fri, May 8, 2009 at 6:51 AM, marius d. <marius.dan...@gmail.com> wrote: > > > Personally I'd be very reluctant exposing that to applications as this > > is Lift implementation specific and exposing an API tight to that > > leads to unnecessary coupling. > > While I don't like unnecessary coupling, either, I do like simple profiling. > > > > > But why do you really need this? ... just for statistical > > purposes? ... I'm not sure about the relevance of such number. > > I want to get an idea about the growth of functions stored in the session. > I > have a idea that might cut the number of functions, under certain > circumstances. > > > Br's, > > Marius > > > On May 7, 10:22 pm, Oliver Lambert <olambo...@gmail.com> wrote: > > > Any chance of exposing a getter on messageCallback that would return some > > > statistics (the number of functions being stored would be a good starting > > > point)? > > > > On Thu, May 7, 2009 at 11:21 PM, marius d. <marius.dan...@gmail.com> > > wrote: > > > > > Just FYI ... > > > > > Things in this area are may change a bit once JQuery fixes the bug > > > > related with namespaces.This was the main reason why we had to deviate > > > > from Dave's original idea of using lift:gc attributes. > > > > > Br's, > > > > Marius > > > > > On May 7, 3:47 pm, Oliver Lambert <olambo...@gmail.com> wrote: > > > > > Ah, you mean messageCallback - The joys of private variables. > > > > > thanks again > > > > > Ol > > > > > > On Thu, May 7, 2009 at 9:55 PM, marius d. <marius.dan...@gmail.com> > > > > wrote: > > > > > > > Please see LiftSession. > > > > > > > On May 7, 1:41 pm, Oliver Lambert <olambo...@gmail.com> wrote: > > > > > > > Thanks for this. I would like to look at the code that actually > > holds > > > > the > > > > > > > storage container and profile it. Any pointers on which class to > > look > > > > at > > > > > > s a > > > > > > > starting point? > > > > > > > Ol > > > > > > > > On Thu, May 7, 2009 at 7:17 PM, marius d. < > > marius.dan...@gmail.com> > > > > > > wrote: > > > > > > > > > In short the current Lift GC is: > > > > > > > > > 1. Each page has an ID > > > > > > > > 2. Each mapped function is associated with the page ID > > > > > > > > 3. There are periodical Ajax request sent from the page that > > are > > > > > > > > refreshing the timestamps on the mapped functions > > > > > > > > 4. Mapped functions that exceeded the expiration time are de- > > > > > > > > referenced hence become eligible for garbage collector. > > > > > > > > > Br's, > > > > > > > > Marius > > > > > > > > > On May 7, 10:15 am, Oliver Lambert <olambo...@gmail.com> > > wrote: > > > > > > > > > I'm trying to get an understanding how garbage collection is > > > > > > implemented > > > > > > > > in > > > > > > > > > Lift. > > > > > > > > > Any pointers on what scala classes do the actual work? > > > > > > > > > > While I'm at it, S.functionMap appears to only return > > functions > > > > that > > > > > > were > > > > > > > > > "recently" bound. Does S._functionMap, contain the functions > > > > being > > > > > > > > garbage > > > > > > > > > collected? > > > > > > > > > > cheers > > > > > > > > > Oliver --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
