Возможно ли получить поток для сборки, сгенерированной в памяти с помощью CodeDOM?

Question

В некоторых моих тестах мне нужно сгенерировать несколько сборок, а затем «декомпилировать» их, используя ICSharpCode.Decompiler, который использует Mono.Cecil для проверки сборок.

По соображениям производительности я хотел бы сгенерировать сборку в памяти, чтобы избежать дискового ввода-вывода.

Ниже вы можете найти код, я намерен использовать:

var cdp = CodeDomProvider.CreateProvider(CodeDomProvider.GetLanguageFromExtension("cs")); 

var p = new CompilerParameters { GenerateInMemory = true } ; 

var cr = cdp.CompileAssemblyFromSource(p, sources); 
if (cr.Errors.Count > 0) 
{ 
    throw new Exception(cr.Errors[0].ErrorText); 
} 

// !!! I'd like to avoid building/loading the assembly to/from disk 
// var assembly = AssemblyDefinition.ReadAssembly(assemblyPath, readerParameters); 

// Instead, I'd like to do something like: 
Stream assemblyStream = GetAssemblyContentAsStream(cr.CompiledAssembly); 

var assembly = AssemblyDefinition.ReadAssembly(assemblyStream, readerParameters); 

var dc = new DecompilerContext(assembly.MainModule); 

var astBuilder = new AstBuilder(dc); 
astBuilder.AddType(typeToBeConverted); 

var output = new StringWriter(); 
astBuilder.GenerateCode(new PlainTextOutput(output)); 

Таким образом, вопрос: Можно ли реализовать GetAssemblyContentAsStream()?

Answer 1

По соображениям производительности я хотел бы сгенерировать сборку в памяти, чтобы избежать дискового ввода-вывода.

Это один из великих мифов программирования. Современные операционные системы слишком умны, чтобы сделать дисковый ввод-вывод узким местом. Ваша программа фактически не записывает сборку на диск, она записывает ее в кэш файловой системы. ОЗУ. Запись на диск происходит позже, намного позже, в потоке ядра, который работает в фоновом режиме и не влияет на perf.

Очень похоже, что «память» как оперативная память - тоже миф. Программы выделяют виртуальную память. Это не память, это пространство, выделенное в файле подкачки. На диске. Задача операционной системы - сделать это пространство доступным для программы, когда это необходимо. Отображение размещения файла подкачки в ОЗУ. Запись на диск происходит позже, намного позже, в потоке ядра, который выполняется, когда другой процесс нуждается в ОЗУ.

Посмотрите сходство? Нет никакой разницы. Единственный возможный побочный эффект, который вы могли бы наблюдать, - это когда вы запускаете машину, которая имеет очень ограниченный объем оперативной памяти. Когда в кеше файловой системы недостаточно места, поэтому программа должна дождаться, пока данные будут записаны в файл. Такая машина также с большим трудом сделает RAM доступной для вашей программы. Он должен выкидывать страницы ОЗУ, используемые другими процессами (или вашими собственными), записывая их на диск. Другими словами, ваша программа будет медленной, чтобы начать работу, а не медленно, чтобы закончить работу. Чистая разница близка к нулю.

Размер сборки never накладывает нагрузку на объем оперативной памяти, доступный для кеша файловой системы на современной машине. Легкий гигабайт как минимум. Поэтому просто не беспокойтесь, вы никогда не увидите улучшения производительности.