请教高手：如果扩大程序使用的栈空间？

ming_study

我个人觉得，写程序的遵循几个原则：
1，程序能够实现预期的功能，程序运行稳定。
2，程序扩展性（易读，易修改）。
3，程序效率（现在的硬件，已经不是以前那样的了）。

请补充指正！

大马虎

没想到一个问题居然能够说到这么多方面，这些都是做程序和行业的通病，不是一个人两个人的问题。

FH

原帖由 "ming_study" 发表：
我个人觉得，写程序的遵循几个原则：
1，程序能够实现预期的功能，程序运行稳定。
2，程序扩展性（易读，易修改）。
3，程序效率（现在的硬件，已经不是以前那样的了）。

请补充指正！

如果是单任务系统，那就差不多了。但是多任务系统呢？必须考虑到程序对系统和其它任务的影响达到最小。
现在内存是大了，CPU是快了，但是CPU要分时给大家用，内存也要分配给别的任务，写程序不能只考虑自己，就像做人。

quil

还有，这个论坛管的太严了，这样的帖子还是越多越好，FH怎么不做斑竹啊。

ming_study

写程序要根据实际的需要来定的。

Yerk

我不了解其他系统如何，但FreeBSD需要调整内核参数，比如我的参数：

options   MAXDSIZ=(1600UL*1024*1024)
options   MAXSSIZ=(1024UL*1024*1024)
options   DFLDSIZ=(1600UL*1024*1024)

表示堆栈的大小是第二个，1G空间。

FH

[quote]原帖由 "quil"]还有，这个论坛管的太严了，这样的帖子还是越多越好，FH怎么不做斑竹啊。[/quote 发表：

因为FH没有责任心，呵呵。

zxw01

晕,还能言归正传呢

柳五随风

我不同意FH关于内存分配的说法.MALLOC用来做BUFFER POOL尽管不完美,但不失为一种好方法.MALLOC使用的得当的话,并不会影响性能.之所以使用MALLOC分配大存储空间,也主要是考虑到OS的VM处理被频繁调度所产生的负面影响影响了系统的整体性能,并且,MALLOC分配的"VIRTUAL MEMORY"大小和实际OS分配的PHYSICAL MEMORY大小没有任何关系,OS仍然是通过VM子系统调度的,用MALLOC分配大存储单位也是为了避开VM子系统的开销而已,并且,这样的例子在现实系统中是很正常的.
比如,RDBMS,或者TP,SOA等东西,他们需要支持大数量的并发访问,需要一个在非线性的计算环境中实现线性的性能的话,不采用BUFFER技术,不采用并发处理怎么可能能做到?
WINDOWS慢的原因,和存储分配的大小有关系,但是,问题的根子不在存储分配自身,而在于WINDOWS自身,WINDOWS的MACRO KERNEL模式,和他自己的VM管理子系统对大资源的支持都不好.
256MBUFFER很正常.

思一克

同意柳五随风的说法。

还有，缺省的STACK大小对于一个好的正常的程序是不许要扩展的。
如果你发觉你的程序STACK益出了，需要的比系统DEFAULT STACK大小还大，那么十有89你写的程序有问题---大的变量不应该在栈中。

还有，除非非常频繁地malloc，free非常小的MEMORY，malloc对程序性能不会有什么影响。因此不需要多此一举自己再搞个什么MEM管理。malloc库已经做的很好了。

仅仅malloc分配的大小不影响速度。比如

1. 
   
2. #include <stdio.h>;
   
3. 
   
4. #define BUF_SIZE 2*1024*1024
   
5. 
   
6. main()
   
7. {
   
8. char *cp;
   
9.     cp = malloc(BUF_SIZE);
   
10.     free(cp);
    
11. }
    

复制代码

BUF_SIZE和速度无关，你分配1024字节或256M，速度应该一样（至少在LINUX）。因为这里并没有分配物理内存。