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 -~----------~----~----~----~------~----~------~--~---
