Ayende @ Rahien

Rob R commented on Runtime code compilation & collectible assemblies are no go

Sat, 25 Sep 2010 14:45:34 GMT

How about using the IronPython interpreter from c# and pass in the linq query as a python script.

Ayende Rahien commented on Runtime code compilation & collectible assemblies are no go

Wed, 01 Sep 2010 09:18:23 GMT

John, Making them MBRO would actually increase the timing, since you would have a lot more cross app domain chatter.

John Fisher commented on Runtime code compilation & collectible assemblies are no go

Tue, 31 Aug 2010 17:14:31 GMT

I've never looked at Raven code, but what are JObject and JProperty? Are they MarshalByRef objects? If they are not, changing them may provide the speed you need.

Frans Bouma commented on Runtime code compilation & collectible assemblies are no go

Wed, 25 Aug 2010 08:47:30 GMT

The binary serializer in .net is very slow. You should implement (if you can), your own serializer, which is actually pretty simple (Implement ISerializable and then simply do it in the GetObjectData and the ctor for deserialization to hook your own serialization stuff). Your own serialization code should not branch out to the .net one but should simply create a byte[] which you add to the info object. This is _very fast_ (and also compact in data, most of the time). See Simon Hewitt's work: [www.codeproject.com/kb/dotnet/FastSerializer.aspx](http://www.codeproject.com/kb/dotnet/FastSerializer.aspx) This might shave off miliseconds per call, so in the end it will benefit greatly

Rafal commented on Runtime code compilation & collectible assemblies are no go

Wed, 25 Aug 2010 08:41:58 GMT

Now you are solving a problem that would not exist if you chose a different technology for your product. An interpreted query / data manipulation language would be much better.

Chris Wright commented on Runtime code compilation & collectible assemblies are no go

Wed, 25 Aug 2010 01:22:55 GMT

Could you serialize the expression trees that you generated in another appdomain? Should be good enough if you don't need to run them directly.

Demis Bellot commented on Runtime code compilation & collectible assemblies are no go

Wed, 25 Aug 2010 01:03:04 GMT

Nice use of the 2nd App Domain, its similar to some of the impressive stuff that Second Life is doing with Mono to speed up their scripts: [http://www.youtube.com/watch?v=QGneU76KuSY](http://www.youtube.com/watch?v=QGneU76KuSY) Since you're spending so much time Serializing you might want to consider a different serializer @marcgravel's protobuf-net is about 8-9x faster than Microsofts BinaryFormatter. Otherwise if you still want to use JSON you should be able to get a perf boost with my JsonSerializer which is around 3x quicker than the other JSON serializers out there atm: [http://www.servicestack.net/mythz_blog/?p=344](http://www.servicestack.net/mythz_blog/?p=344)

Steve Py commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 22:11:21 GMT

Probably a silly question, but why do you kick off a compiler instance instead of using SRE?

Ajai Shankar commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 21:57:20 GMT

Assuming dynamic method is what we are after, and speaking of hackish, here is one crazy link: [blogs.msdn.com/.../...odinfo-to-dynamicmethod.aspx](http://blogs.msdn.com/b/haibo_luo/archive/2006/11/07/turn-methodinfo-to-dynamicmethod.aspx)

Matt Warren commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 21:55:31 GMT

@fschwiet - I think the general idea for Ravan is that an index created as a string should be simple. I believe this was a design decision to make people use simple indexes. There is the option of compiled indexs, see the Event-Sourcing sample at [github.com/.../Raven.Bundles.Sample.EventSourci...](http://github.com/ravendb/ravendb/tree/master/Samples/Raven.Bundles.Sample.EventSourcing.ShoppingCartAggregator/). Although the enum case you're see is somewhere inbetween, you shouldn't have to write a compiled index just to get enum's to work.

Frank Quednau commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 21:40:18 GMT

It may sound a bit hackish, but with Mono.Cecil it could be possible to extract the ILCode you create by doing the compile you do today. You could then feed the ILCodes into a method of your dynamic assembly, which makes it elligible for collection.

tobi commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 19:43:07 GMT

You could also run the whole server in a second appdomain so you do not have to do _any_ marshalling. Then you recycle that domain periodically from the main domain that acts as a coordinator.

tobi commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 19:39:19 GMT

Try to find out what is causing the slowdown. Maybe it is erialization (write a custom serializer that is 100 times faster) or maybe it is the infrastructure that you cannot control (use batching to transfer multiple objects). LambdaExpressions can be compiled to dynamic methods (LExpression.Compile(ILGenerator)). That might help too.

SHSE commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 17:26:37 GMT

I tried WCF with NetNamedPipes and got 500ms vs 4000ms. Here is the code [http://pastebin.com/MMg5SCup](http://pastebin.com/MMg5SCup).

Justin Chase commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 17:15:38 GMT

I believe that it does support it actually. Expression.Dynamic(...); Should allow you to do the equivalent of the dynamic keyword inside of a linq expression. [msdn.microsoft.com/en-us/library/dd324059.aspx](http://msdn.microsoft.com/en-us/library/dd324059.aspx) However the Dynamic sample stuff was created in .net 3.5 time frame and does not include support for a lot of the new linq expressions such as Dynamic and Block.

LL commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 17:14:33 GMT

@fschwiet, MEF directory catalog also leaves assemblies in memory, even if you remove them from the directory and refresh the catalog.

fschwiet commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 16:32:52 GMT

When I started looking at dealing with enums in the linq queries for RavenDB, I came to appreciate the difficulty of what you're trying to do. One problem, as soon as people can use arbitrary linq expressions, they want to mix in arbitrary code from some odd DLL that isn't necessarily on the server. I wonder if after you solve the one problem if you'll still hit another wall. I wanted to mention some approaches that came to mind, in case you haven't considered them: 1) RavenDB, via MEF, supports adding extensions via DLL copy. I wonder if it would be easier to just require the client to send a DLL to the server that has their queries precompiled. This way they could include arbitrary code. The user has more work to do when they change their queries, but the raven usage model is already such that you're supposed to think about your queries early. 2) If this app domain business is to support the Map/Reduce linq expressions, and not the query expressions, I wonder if the whole indexing business could live in a separate app domain, so you're not crossing app domain boundaries so much.

LL commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 15:53:56 GMT

@Justin, the problem is that Raven uses C# 'dynamic' objects. LINQ expressions do not support them directly.

Justin Chase commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 15:32:04 GMT

I have created a Pattern Matching library that parses DSLs or a general purpose programming langauge (of my creation) that looks similar to C# for doing dynamic expressions that get built into collectible assemblies. Theoretically you could do this with boo also once it's ported to .net 4. [http://metasharp.codeplex.com](http://metasharp.codeplex.com) example: [metasharp.codeplex.com/.../6635d57d84f1](http://metasharp.codeplex.com/SourceControl/changeset/view/6635d57d84f1#src%2fsamples%2fSongSample%2fDynamicSongBuilder%2fDynamicSong.template) Actually there are two things going on in that sample. A DSL is parsed into an AST then that AST is passed into this template, this template produces code that gets compiled into linq expressions, which get compiled into a lambda expression and executed, collected etc.

LL commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 14:43:01 GMT

Hi Ayende, I've been using the Microsoft's Dynamic sample mentioned above for years in production. It is based on DynamicMethod and so does not generate new assemblies. However, it does not support C# 4.0 "dynamic". LL

Ernst Naezer commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:54:33 GMT

I gave the NamedPipe suggestion a try. I'm not a WCF expert so I'm probably doing something wrong / funky with the serializer stuff. But it looks quite slow. 265ms v.s. 25434ms on my machine. So around 100 times slower. But then again.. it could be I'm doing something stupid. code: [http://pastebin.com/mxuydvDf](http://pastebin.com/mxuydvDf)

Daniel Grunwald commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:38:39 GMT

> Looks like you might end up using (or likely writing, given your history ;)) a C# parser to generate an AST you can translate in an expression tree. That's nontrivial as you need to implement the C# type system, overload resolution, etc. Even just the parsing part is extremely complex for C# (think of all the ambiguous syntax like "M(a d(7))" or near-ambiguous like "bool b = a is B?;" vs. "bool b = a is B ? c:d;") But if you are interested, I wrote some hacky prototype of this a year ago, based on the SharpDevelop C# code-completion system. It's not that hard if you use the right components: SharpDevelop solves many of the nasty issues understanding C# code, and Linq.Expressions solved many of the nasty issues generating IL. Of course there will be subtle differences to the actual C# semantics, but it might work OK for Ayende's usecase. For our own usecase, we settled on using csc.exe and living with resulting the memory leak.

Philip commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:38:05 GMT

Here's what I had to do in a (not very) similar case: I took the code that was static and would normally be communicating across the appdomain boundary and injected it into each appdomain when built. Then I had a slim appdomain manager that took requests and routed them to the appdomains to be worked on entirely there. the downside to this is extra code in every appdomain, and writing the code to inject my base compiled code into them. The tricky thing was just finding the right spot to put the boundary - make all of the work into a single cross-boundary call was the best case scenario, but not always possble.

Paul Hatcher commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:18:42 GMT

One obvious thing that doesn't work is batching the calls, i.e. passing a list of values to be transformed so that the interface is not so 'chatty' - quick experiment showed that it only improved things by <10%

configurator commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:14:35 GMT

Oh, scratch that. They're both on the same (remote) appdomain...

configurator commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:13:21 GMT

What happens if you try the same with two different assemblies for the Transformer and RemoteTransformer classes? I'm thinking there may be some smart optimization going on in the simple case since your loop is pretty simple.

Andrew Davey commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:11:01 GMT

Looks like you might end up using (or likely writing, given your history ;)) a C# parser to generate an AST you can translate in an expression tree. Alternatively, could you avoid repeated calls to the other app domain by making it get the documents to process, rather than sending each one over?

Ajai Shankar commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 13:00:02 GMT

Hi Ayende Have you already considered the dynamic query sample that ships with VS2008? ( [http://msdn.microsoft.com/en-us/library/bb397982](http://msdn.microsoft.com/en-us/library/bb397982)(VS.90).aspx) I had used it some time back, there was some restriction on it only supporting method calls on some basic types, but very easy to around that :-) It does compile expressions into a dynamic method which I think is ideal for the Raven scenario. I also noticed a reference to NRefactory (LInqPAD uses it I think) somewhere, haven't used it but assume you could walk it's AST and transform 1:1 to a expression tree & compile to lambda? Ajai

andres commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 12:55:46 GMT

Can you do that with expressions? like [weblogs.asp.net/.../...-dynamic-query-library.aspx](http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx) ...

Samuel Jack commented on Runtime code compilation & collectible assemblies are no go

Tue, 24 Aug 2010 12:36:08 GMT

In my experience, WCF using a NetNamedPipesBinding is much faster than remoting. The new default configuration feature in .Net 4.0 makes it pretty painless to use.