Creating (or converting) SimpleBlocks
Locked
Creating (or converting) SimpleBlocks
 
|
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 [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Creating (or converting) SimpleBlocks
|
|
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" <[hidden email]> wrote:
Hi there, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Creating (or converting) SimpleBlocks
|
|
In reply to this post by GLASS mailing list
Johan,
Here's the skinny from engineering: > As Paul mentioned, we did add a number of optimizations to 3.x based on Paul's findings > In v3.2 and above , a Simple block does reference it's home method which > in turn references the class in which the home method was compiled. But those references > are only for debugging information. If you create a block with > ' [ :a : b | a < b ]' evaluate > Then the class of the home method is nil . > > For 3.4 we could consider making a SimpleBlock not reference its home method, > but then in debugging situations you would not be able to determine where the > block was created . > > We could discuss further if you want Dale On 06/11/2016 12:53 AM, Johan Brichau via Glass 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 > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
| Free forum by Nabble | Edit this page |