﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on Trusting the benchmark</title><description>You need to use PersistentProxyBuilder for that.
</description><link>http://ayende.com/2879/trusting-the-benchmark#comment5</link><guid>http://ayende.com/2879/trusting-the-benchmark#comment5</guid><pubDate>Wed, 24 Oct 2007 07:53:07 GMT</pubDate></item><item><title>Philip Laureano commented on Trusting the benchmark</title><description>Hi Ayende,
  
  
I'm interested in redoing the benchmark to time the actual proxy-to-target method calls for each library, but I can't seem to figure out how to persist the proxies that Castle generates to disk. I want to compare the IL generated by each library, but I can't do that unless I can get it to save the AssemblyBuilder to disk. Do you know how to do this? I'm not very familiar with Castle.DynamicProxy2's object model, so if you could help me, I'd certainly appreciate it. Thanks!
</description><link>http://ayende.com/2879/trusting-the-benchmark#comment4</link><guid>http://ayende.com/2879/trusting-the-benchmark#comment4</guid><pubDate>Tue, 23 Oct 2007 23:18:21 GMT</pubDate></item><item><title>Ayende Rahien commented on Trusting the benchmark</title><description>Philip,
  
One of the goals of DP2 is that it will be possible to work with it without being aware of all the details of IL generation.
  
We are a diverse group, and not everyone can read IL. Having the AST mean that people can work with it in a much simpler way.
  
It also mean that it is simple to add new features, or fix bugs.
  
  
Above all, it means that the AST make the code much more maintainable.
</description><link>http://ayende.com/2879/trusting-the-benchmark#comment3</link><guid>http://ayende.com/2879/trusting-the-benchmark#comment3</guid><pubDate>Sat, 20 Oct 2007 13:00:40 GMT</pubDate></item><item><title>Philip Laureano commented on Trusting the benchmark</title><description>Thanks for the comments, Ayende. Actually I'm more impressed with what you did with Castle DP2--I don't think I would have had the patience to generate an entire AST to abstract myself away from generating the IL myself--and believe me, that takes far more patience than just having to deal with the IL directly. So for that, my hat definitely goes off to you and the rest of the Castle team. *bow*
  
  
For me, however,  it seemed to be a bit of overkill to create an entire abstraction layer over generating IL, especially since the only purpose of the code generation is to forward those calls back to an interceptor. While I understand that IL certainly has a steep learning curve and is difficult to generate, I still have to question whether or not having all that  ASTcode is actually necessary.
  
  
Based on what I've seen in Castle DP2, there seems to be an underlying assumption here that by writing an abstraction layer over the IL, you immediately protect yourself from generating unverifiable (or worse, invalid) IL code--all at the expense of simplicity. 
  
  
In other words, instead of spending all that time coding that whole AST, wouldn't have been easier just to become proficient with IL and write only the code that you need? Do you really need to invent a second language (the AST) within your  favorite language just to generate another one ( IL)? Do you realize that you're using two languages to generate one (C# + AST = IL)? Whatever happened to just generating IL?
  
  
I'm a big fan of Castle, but it seems like you guys invented a fifth wheel since you didn't want to get your hands dirty in IL.
</description><link>http://ayende.com/2879/trusting-the-benchmark#comment2</link><guid>http://ayende.com/2879/trusting-the-benchmark#comment2</guid><pubDate>Sat, 20 Oct 2007 07:56:29 GMT</pubDate></item><item><title>Casey commented on Trusting the benchmark</title><description>Any benchmarking of such a small component of a system in isolation is fairly futile beyond checking you don't have bottlenecks or concurrency issues. 
  
  
Benchmarking for real performance should be done on a real implementation, and then the offending components can be dealt with in situ, which is when IoC becomes so powerful.
</description><link>http://ayende.com/2879/trusting-the-benchmark#comment1</link><guid>http://ayende.com/2879/trusting-the-benchmark#comment1</guid><pubDate>Wed, 17 Oct 2007 07:06:23 GMT</pubDate></item></channel></rss>