to 9.10.2025 klo 19.11 Chris Colman ([email protected]) kirjoitti:
> > On 9/10/2025 9:48 pm, Andrea Del Bene wrote: > > I think it might be useful creating a issue (or at least a branch) to > > collect some ideas about this topic. I'll try to do something myself in > the > > next days. > > > > On Thu, Jul 17, 2025 at 11:01 AM Andrea Del Bene <[email protected]> > > wrote: > > > >> I'm in favor too of expanding Lambda adoption in Wicket. I remember some > >> of this support was eventually moved to WicketStuff due to the memory > >> concern, but I think it's better giving users the option to accept the > >> right trade-off between memory consumption and a cleaner code. > >> > >> On Wed, Jul 16, 2025 at 1:25 PM Martijn Dashorst < > >> [email protected]> wrote: > >> > >>> On Tue, Jul 15, 2025 at 3:12 PM Richard Eckart de Castilho < > >>> [email protected]> > >>> wrote: > >>> > >>>> Does the memory usage matter a lot? > >>> > >>> Yes. In (large) applications typically there's a lot of components in > >>> memory. > >>> > >>> I'll dig up some statistics from one of our production servers with a > lot > >>> of users. > >>> > >>> Wrt. the this pointer: yeah, that sometimes comes up. However, most of > the > >>>> time > >>>> > >>> I fill in method handles anyway. In those cases where I don't I > typically > >>>> assign > >>>> the component to a variable that I can use inside the lambda instead > of > >>>> the this. > >>>> I had also thought of passing in the component as an argument to the > >>>> lambda. > >>>> > >>> The issue is that each lambda takes a reference which increases the > >>> footprint of Component considerably. For a stateful serverside web > >>> framework we can't ignore this. > >>> > >>> Joined the ASF channel ;) > > Exactly. I know many of these new-ish language features are nice and > shiny and "mathematically puritan" (if that's important) but we still > have to consider that these apps must run on real computers and so the > extra RAM, GC load and CPU cycles consumed have to be considered. > > We had an app that ran for years without any performance or reliability > issues until one day a developer took it on himself to replace many low > level methods that returned an object to return an 'Optional' typed to > the object's type instead. It had payroll report generation code, > iterating over hundreds of thousands of employees with 100 or so fields > per employee record. The extra object (Optional instances) being created > at every one of these previously efficient field level method calls > caused the Garbage Collector to have a hernia and code that ran fine for > years on modest hardware was suddenly throwing regular OOMs and having > the system appear to freeze up. > > The OOMs were not the good type of OOM either - they were these bad boys: > > "Excessive Garbage Collection Time: > > If the JVM spends an inordinate amount of time on garbage collection > (e.g., 98% of CPU time) and recovers very little memory (e.g., less than > 2% of the heap), it can throw an OutOfMemoryError: GC overhead limit > exceeded. This indicates that the application is making little progress > and is primarily busy with garbage collection." > > As mentioned by others there are also issues with access to variables > with shiny lambda's. Too many times I have thought a shiny lambda would > nicely replace a simple 'for' loop only to discover that the non trivial > code needed at each iteration required access to non "finalisable" > variables in the outer method block and so then we have to invent > intricate ways to provide access... at some point you realize the "nice > and shiny" thing isn't something to be blindly adopted everywhere. > > There's a reason Linux is still written, mostly, in 40 year old C. Some > recent efforts to convert some parts to the latest shiny thing, Rust have ended up with lower performance than their C based originals. > 1+ > > Regards, > Chrisco > > >>>> Do you think this is something limited to Wicket Bootstrap? Or would > you > >>>> just > >>>> want to explore the concepts in that space before considering them for > >>>> Wicket Core? > >>>> > >>> It just came up in that channel. No particular reason. > >>> > >>> For whether or not it belongs to wicket proper? I dunno, but that is > >>> something we should start discussing to get some new life in the > project > >>> other than the odd bugfix. The programming model hasn't really changed > >>> since Java 5, so we're due a refresh. > >>> > >>> Martijn > >>> > >> > >> -- > >> Andrea Del Bene. > >> Apache Wicket committer. > >> > > >
