在编程时,这一直是我心中的疑问,所以我想在它真正影响我之前说出来。
我应该更担心什么?应用程序使用的内存还是它所需的性能。我的意思是,我应该专注于减少应用程序的内存使用量,并使用更多的性能(例如通过数据库加载并在使用后丢弃),还是减少性能使用并使用更多内存(例如缓存)。
我的应用程序条件: - 这是一个服务器应用程序,不适合在桌面等其他设备上运行,我有6GB的RAM和四核处理器。
在编程时,这一直是我心中的疑问,所以我想在它真正影响我之前说出来。
我应该更担心什么?应用程序使用的内存还是它所需的性能。我的意思是,我应该专注于减少应用程序的内存使用量,并使用更多的性能(例如通过数据库加载并在使用后丢弃),还是减少性能使用并使用更多内存(例如缓存)。
我的应用程序条件: - 这是一个服务器应用程序,不适合在桌面等其他设备上运行,我有6GB的RAM和四核处理器。
你的问题已经得到了很多类似于禅宗佛教的回答,我希望能做得更好。
内存限制是硬性的:如果超出限制,即使有虚拟内存,你的应用程序也会变得缓慢不堪,成为大家嘲笑的对象。
CPU时间是没有限制的:你的应用程序将花费需要的所有时间;希望它足够并行,以至于所有4个CPU在大部分时间内都可以发挥最大效率,直到你的应用程序完成。
许多计算机科学问题有多种解决方案,其中包含不同的内存与时间之间的权衡。因此:在使用至少一半内存之前,要慷慨地使用内存(如果这有所帮助;不要浪费内存!),但是要停下来留出足够的内存,以免在特殊情况或意外情况下超出限制。
现在,你已经分配了内存资源,可以尝试通过代码微调获得更小的性能提升。但不要过度纠结。
完成了。
P.S. 如果它不能正确可靠地工作,那么前面的所有努力都是徒劳的。时刻记住这一点!
祝你好运。
这个问题与编程本身一样古老。不幸的是,答案是“要看情况”。如果您正在为一个有32GB内存的系统编写应用程序,并且您的软件是唯一运行的内容,那么您应该编写代码以利用它。另一方面,如果您正在编写将在嵌入式系统上运行的代码,那么您可能应该尽可能地使用较少的内存。最重要的是,您要意识到这些权衡,对您的代码进行分析,并优化最大的瓶颈。
针对不同的应用程序,你会得到不同的答案,实际上这取决于具体情况。除了以下一句话,没有一个通用的答案涵盖所有情况:
有时候软件可以过度思考。
具体来说,大多数操作系统在缓存磁盘 I/O 方面表现出色。举个例子,如果你正在处理大量 SQLite 数据库连接,那么在你建立几个连接后,操作系统很可能已经将整个内容缓存在内存中。在大多数情况下,不要过度思考操作系统。
没有一种正确的选择-这取决于您的应用程序及其要求。但是,通常只能选择一种-您通常无法同时最大化性能和减少内存消耗(如果有的话)。如果这是任何关键系统,客户应指定内存的最大限制和/或性能的最低限制-如果他们没有这样做,他们应该这样做。
我目前在处理与我的当前项目相同的困境。有三个方面:可读性,速度和内存。在我拥有的替代解决方案和库中,每个方面都很好。我的结论是(按降序排序):
主要目的是编写未来的代码。代码有生存、生活和繁荣的渴望。没有什么比良好、简单的代码更好:美丽的语法、易于遵循的逻辑和直观的步骤。选择最可读的代码。
服务和应用程序按顺序共享CPU:一个接一个地运行,并经常等待许多微秒。它们并行共享RAM:所有人都占用一定的内存。
实现一个解决方案,确保在实际情况下内存永远不会超过限制。请记住,操作系统和其他应用程序与您共享内存。 RAM的几个百分点对于您的应用程序来说应该足够了。 然后,您可以考虑解决速度瓶颈(太多循环或等待时间过长)。
它们两个都很重要。你可能想要将某些对象缓存到内存中以获得更好的性能,这可能会增加内存占用。另一方面,如果你的应用程序花费大量时间进行垃圾回收(如在 .net 中),或者有未释放内存的非托管资源,那么你将遇到性能问题。
最好不要抽象地思考,而是从具体的设计角度出发。
如果你的RAM用尽了,你会后悔的,所以尽可能保持数据结构的简洁和简单,即使看起来你可能需要编写一些看起来效率低下的循环。因为担心性能而复杂化代码和数据结构是过早优化的本质。尽管人们反对过早优化并声称他们不这样做,但他们仍然会以可怕的程度这样做。
当它正在工作并且做你需要它做的事情时,如果你实际上有一个或多个性能问题,那么处理性能。通常的方法是使用分析工具,但这是我喜欢的方法。
小心多核。并行和线程允许您在时间上重叠地获取多个代理,例如磁盘头、CPU或人类客户端。例如,如果您的进程是I/O限制的,则尝试在多个核上执行它们不会有太大帮助,反而可能会损害性能。如果只有一个物理磁盘驱动器,则尝试重叠I/O限制的线程可能不会带来太大的收益,并且可能会损害性能。另一方面,如果您对每个用户有一个线程,那可能是有意义的,因为这些线程大部分时间都在等待用户。
即使您提供了规格,这仍然取决于应用程序将要处理的工作负载。
因此,首先获得您的应用程序的工作版本。然后进行分析,查看瓶颈在哪里。(过早地进行优化是万恶之源!--唐纳德·E·科诺斯)