Some time ago we discussed the crash that could possibly be due to flooding WebKit with too many view initialization in too short a time window. (Remains to be confirmed.)
@jmercouris Suggested that we delayed the initialization of the web view until use, in other words, we made it lazy.
There is a general approach for this: slot-unbound.
We can specialize it for class/slot pairs to initialize the slot value on access.
Leave the slot :unbound in the define-class declaration.
That easy!
To reduce verbosity, we could even make a metaclass to introduce the :lazy t slot option which would essentially do the above.
(Am I reinventing the wheel here? Maybe lazy-classes already exist as a library?)
It could be a massive performance (speed and memory wise) if you think about it. For instance, we could create millions of buffers, do some complex operation, then kill them all or keep them somewhere in memory. But as long as we do not display the buffers, all this would be super fast.
As I said, the above is a general approach, so it would not apply to just buffer but any class with some non-trivial slots.
I know of no such library. I've been trying to remember a snippet of code I saw somewhere exactly for this purpose. I will update if it comes to mind, however unlikely.
Some time ago we discussed the crash that could possibly be due to flooding WebKit with too many view initialization in too short a time window. (Remains to be confirmed.)
@jmercouris Suggested that we delayed the initialization of the web view until use, in other words, we made it lazy.
There is a general approach for this:
slot-unbound
.:unbound
in thedefine-class
declaration.That easy! To reduce verbosity, we could even make a metaclass to introduce the
:lazy t
slot option which would essentially do the above.(Am I reinventing the wheel here? Maybe lazy-classes already exist as a library?)
It could be a massive performance (speed and memory wise) if you think about it. For instance, we could create millions of buffers, do some complex operation, then kill them all or keep them somewhere in memory. But as long as we do not display the buffers, all this would be super fast.
As I said, the above is a general approach, so it would not apply to just buffer but any class with some non-trivial slots.