[Glass] Creating (or converting) SimpleBlocks

Paul Baumann via Glass glass at lists.gemtalksystems.com
Sat Jun 11 09:13:58 PDT 2016


Hi Johan,

Yes. There are several tricks for simplifying blocks. One for example is a
domain object that is a proxy for a block (with configurable context as
necessary). A trick like that sometimes encounters unnecessary kernel code
obstacles to polymorphism though. A workaround is then to design the domain
objects to not be block proxies but a near equivalent.

I did a thorough analysis of the costs of complex blocks. My work was
published as a paper and framework named "Efficient Gemstone Enumeration".
It might be possible to still find a copy of it, but the forum site of the
original post is now gone.

The paper showed that 80% reduction of execution time was common by making
enumeration blocks simple. Doing so also practically eliminates running out
of temporary object space. The framework extended collection enumeration
syntax to allow for passing context into blocks as arguments, thereby
leaving the block simple. Application code was optimized with these
techniques. Inefficient gs kernel code was also tuned where complex block
costs were a problem for our code base. My understanding is that my work
influenced the tuning of gs 3.x and so perhaps the gains are not as
dramatic as with earlier releases. I've simplified every kind of complex
block.

Your persistence of complex blocks would bloat the database over time.
Custom sort blocks of a sorted collection are one source of a problem like
that, but some creative coding styles can also find that cost (which seems
to be the case here). Your mention of class method references indicates a
problem partially addressable by code management/release/patch tools. That
problem is why I wrote GemKit to update all methods (including subclasses)
when a class schema is changed.

Reply by email with code of some complex blocks causing grief. I've tuned
more code than anyone else I've met in 23 years of programming. I'm
available for contract work if exceptional performance is important for
your project. I usually tune to achieve a 95% reduction in execution time.
I make efficiency a competitive advantage.

Paul Baumann
On Jun 11, 2016 3:53 AM, "Johan Brichau via Glass" <
glass at lists.gemtalksystems.com> wrote:

> Hi there,
>
> We are creating and storing a decent amount of blockclosures in persistent
> objects. We want these to be simple blocks as they do not need any values
> from their lexical scope and we wish to ensure they do not reference any
> objects that might otherwise be gc’ed.
>
> The way we do this right now is by passing these blocks through the
> following method:
>
> convertToSimpleBlock: aBlock
>         ^ aBlock _sourceString evaluate
>
> I’m not totally fond of this way: it uses a private Gs method.
> However, creating blocks from strings directly in our application code
> makes it harder to use code refactoring tools as the code inside the string
> is not taken into consideration.
> Another way to ensure that block’s lexical scope does not reference any
> undesirable objects is by following a code convention that explicitly
> creates a method in the object that will store it, and mind that there are
> no method arguments. However, some of these blocks are to be created in a
> class method, which would mean they reference that version of the class
> forever (undesirable in the light of future class migrations).
>
> Is there any other way to create simple blocks? :)
>
> Thanks for any suggestions
> Johan
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160611/6d7ae55b/attachment.html>


More information about the Glass mailing list