我有一个.NET解决方案，其中包含多个项目。
已经确定了可以改进的项目的一些潜在热点。
E.g。尽可能考虑三元运算符。
问题是：
询问Visual Studio 2015＆amp; amp; .NET领域。
答案 0 :(得分：2)
用等效的三元运算符替换if语句通常对生成的代码没有任何影响。无论你如何在高级别编写它们，编译器都非常擅长将这些内容优化为完全相同的指令序列。
通常，在没有对代码进行任何实际重组的情况下，代码行数量的减少不会对项目的大小产生任何影响。
重构代码可能会产生影响，但除非你有非常愚蠢的事情，比如完全未使用或完全无用的代码，否则你必须聪明地重构事情，这需要大量工作。
通常，性能和加载时间的改进需要 更多 代码，而不是更少的代码。例如，如果您在启动期间经常访问某个存储库，这会降低您的速度，那么使程序加载速度更快的原因是引入了一种缓存机制，可以减少存储库的命中数。需要添加此缓存机制，以便更多代码。
摆脱未使用的库，将库配置为在启动期间做得更少，只使用几个函数替换库，如果这是您使用的所有功能，通常是最低级的成果。
答案 1 :(得分：2)
就三元运算符而言，它可能比If / Else（Ternary ? operator vs the conventional If-else operator in c#）
慢为了提高性能，请考虑查看您的热点，并查看他们正在做什么。看看你的O（n）表现。例如，您是否经常更新然后使用列表？如果是这样，也许您可以查看内置排序的其他List容器。
或许你可以将一些逻辑移到循环之外;无论是之前还是之后。因为嵌套循环很慢。
你可以使用“一见不醒”的模式而不用担心什么吗？像Task.Run(A);这样的东西。这不会返回结果，但它会启动一个新线程，可能会将您的热点移动到可接受的位置。
并且，了解在优化这些块时，会出现新的热点。
要确定热点的位置，请在VS2015中按照MSDN文章进行操作 https://msdn.microsoft.com/en-us/library/ms182372.aspx
答案 2 :(得分：1)
简短的回答是：这取决于。
有些事情可以让您的代码更高效，例如将计算存储在变量中（如果您计划将结果重新用于其他任务）或使用算法更好地导航数据，而不是逐个遍历每个项目。
但删除不必要的行？并不是的。使用未使用的方法或引用并没有真正增加实际性能方面的松弛。当然，把它放在那里很烦人，但它所做的就是增加编译时间并增加你的项目规模。如果您的程序没有使用它，那么它就不会在性能问题上添加任何其他内容。
你应该考虑的事情是保持DRY（不要重复自己）代码比仅仅＆＃34;美化＆＃34;你的代码。它有助于提高可维护性，可读性，并使团队工作变得更加容易。它是一个名为＆＃34;重构＆＃34;的过程的一部分。你可以找到更多信息here。
答案 3 :(得分：1)
为了好玩，我想我会尝试一点测试。
我想：
我们知道C＃会转换为MSIL，所以它才有意义 有更多的代码，MSIL会越多，因此 负载减慢。
但事实证明情况并非如此。
我尝试动态加载2个dll：
以下示例代码：
private void LoadTest()
{
// Startup test just in case the loader needs priming....
var dll0 = Assembly.LoadFile(@"C:\Users\me\Documents\visual studio 2015\Projects\DeleteMeApp\DeleteMe0\bin\Debug\DeleteMe0.dll");
Stopwatch st = new Stopwatch();
st.Start();
// This dll is nearly empty
var dll1 = Assembly.LoadFile(@"C:\Users\me\Documents\visual studio 2015\Projects\DeleteMeLib1\bin\Debug\DeleteMeLib1.dll");
st.Stop();
var time1 = st.ElapsedMilliseconds;
Stopwatch st2 = new Stopwatch();
st2.Start();
// This dll has over 100,000 lines of code in
var dll2 = Assembly.LoadFile(@"C:\Users\me\Documents\visual studio 2015\Projects\DeleteMeApp\DeleteMeLib2\bin\Debug\DeleteMeLib2.dll");
st2.Stop();
var time2 = st.ElapsedMilliseconds;
}
<强>结果
我不太了解结果。我想也许编译器更加聪明，我的100,000多行代码在某种程度上被编译为空。
所以，我按照这个post查看MSIL，大文件的MSIL代码比小文件多得多。
下一次测试
仍然难以置信，我在100,000多行代码中添加了100,000种不同的public void方法，并重新进行了测试。
ildasm.exe变得反应迟钝，所以我猜测IL非常大。
<强>结论
没有;似乎代码行数与加载时间无关。