Mark Waser wrote: > >> And, from a practical programmatic way of having code generate code, >> those are the only two ways. The way you mentioned - a text file - >> you still have to call the compiler (which you can do through the >> above namespaces), but then you still have to bring the dll into the >> same appdomain and process. In short, it is a huge performance hit, >> and in no way would seem to be a smooth transition. > > Spoken by a man who has clearly never tried it. I have functioning > code that does *exactly* what I outlined. There is no perceptible > delay when the program writes, compiles, links, starts a new thread, > and executes the second piece of new code (the first piece generates a > minor delay which I attribute to loading the compiler and other tools > into memory). >
I have tried it. I was writing code and especially classes to files, compiling and loading them into memory back in the mid 80s. There is no way that opening a file, writing the code to it, closing the file, invoking another process or several to compile and link it and still another file I/O set to load it is going to be of no real performance cost. There is also no way it will outperform creating code directly in a language tuned for it in memory and immediately evaluating it with or without JIT machine code generation. #Net is optimized for certain stack based classes of languages. Emulating other types of languages on top of it is not going to be as efficient as implementing them closer to the hardware. If the IDL allowed creating a broader class of VMs than it apparently does I would be much more interested. > Also, even if it *did* generate a delay, this function should happen > often enough that it is a problem and there are numerous ways around > the delay (multi-tasking, etc). > How would it help you that much to do a bunch of context switching or IPC on top of the original overhead? - samantha ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303