还有,第一次打开界面速度慢,这个就不说了!但是性能差距在,6-7倍,这太夸张了,第一次运行需要1秒钟,而第二次,200毫秒就搞定了。
50 个解决方案
#1
顶者有分
#2
第一次运行需要1秒钟,而第二次,200毫秒就搞定了--->这个很正常,中间码需要转本地码,第二次省略了转的过程,有缓存。
#3
接分,缓存的问题吧
#4
额,这个。
不怎么了解,顶下。
不怎么了解,顶下。
#5
第一次运行会调用相关数据到内存,方便以后调用如静态方法等
#6
自己测程序,比如在一些重要的业务过程,耗时方法等,用stopwatch计时,看这些方法处理数据的性能怎样,写日志记录下来,就知道了啊。
#7
主要是代码解析的问题。
#8
要用.net就得这样,把机器配置升一下,能快些
#9
顶了
#10
软件在长时间开着不使用(可能5-10分钟),然后过5-10分钟后,开始使用,速度会变慢,但是慢了一会,又会快起来,一直使用下去,速度就很快
--->这个问题怀疑与操作系统内存调度有关,长时间不用这个软件,其他进程的数据被刷进高速缓存页面,忽然开始使用时,会卡一下,如果软件占用内存多,卡的时间就长
--->这个问题怀疑与操作系统内存调度有关,长时间不用这个软件,其他进程的数据被刷进高速缓存页面,忽然开始使用时,会卡一下,如果软件占用内存多,卡的时间就长
#11
第一次开始的时候,系统需要配置一下环境,所以比较慢,第二次已经存在了一些必要条件,就快一点
.NET 在一段时间没有使用,会自动释放一些资源
.NET 在一段时间没有使用,会自动释放一些资源
#12
估计是正常的吧。
#13
帮顶,个人认为有必要重构一下代码,将通过一些算法优化一下线程,情况会好一些.
#14
我顶顶吧。
楼上的都说了。
楼上的都说了。
#15
同意楼上
其次:你线程是不是空闲时间占资源太多,见意在空闲时间用,Thread.Sleep(1000);空闲一秒钟
再次:你程序中写的静态变量是不是过多,所以会产生这样结果,静态变量是程序使用中一直加载在内存的,所以在你内存过小的情况下,会转存硬盘的扩充缓存
其次:你线程是不是空闲时间占资源太多,见意在空闲时间用,Thread.Sleep(1000);空闲一秒钟
再次:你程序中写的静态变量是不是过多,所以会产生这样结果,静态变量是程序使用中一直加载在内存的,所以在你内存过小的情况下,会转存硬盘的扩充缓存
#16
up
#17
帮顶吓.
#18
同意10楼
#19
先顶
#20
不懂
#21
楼上的都说很详细了,软件没有什么问题。
#22
接分.............
#23
应该是与操作系统有关吧,友情帮顶。
#24
缓存
#25
顶,不明真相的围观群众
#26
应该和缓存有关系。
#27
第一次打开慢是老问题了,然后再打开,应该就是缓存了。
#28
帮顶下~~
#29
顶
#30
这种状况,在有动态访问数据库的情况下,更为显示。
连接到数据库服务器是个费时的过程。必须建立物理通道(例如套接字或命名管道),必须与服务器进行初次连接,必须分析连接字符串信息,必须由服务器对连接进行身份验证,等等。
ADO.NET中,使用了连接池的优化方法,来管理维护连接。Open时,连接池就会检查池中是否有可用的连接。如果有,直接返回给调用者,而不是建新。 Close 时,会判断该连接是否在最小连接数之内,如果“是”会将连接回收到活动连接池中,而不是真正关闭。以备下次使用。
这样,第一次使用时比较慢,紧接着再用就很快。
如果,长期不用,超过连接的生命周期(有限时的),或着长期不用被连接池优化清理掉了。这就再用,那就和第一次一样,从头再来一遍,当然就慢了。
连接到数据库服务器是个费时的过程。必须建立物理通道(例如套接字或命名管道),必须与服务器进行初次连接,必须分析连接字符串信息,必须由服务器对连接进行身份验证,等等。
ADO.NET中,使用了连接池的优化方法,来管理维护连接。Open时,连接池就会检查池中是否有可用的连接。如果有,直接返回给调用者,而不是建新。 Close 时,会判断该连接是否在最小连接数之内,如果“是”会将连接回收到活动连接池中,而不是真正关闭。以备下次使用。
这样,第一次使用时比较慢,紧接着再用就很快。
如果,长期不用,超过连接的生命周期(有限时的),或着长期不用被连接池优化清理掉了。这就再用,那就和第一次一样,从头再来一遍,当然就慢了。
#31
缓存?
#32
up
#33
.net程序执行过程如下:
1 一个方法执行之前,CLR首先检测Main中代码引用的所有类型,CLR会分配一个内部的数据结构,该数据结构用于管理对所引用类型的访问。
2、当该数据结构被初始化时,CLR将把每一个条目设置 为CLR内部的一个没有正式记录的函数,我们暂且称该函数为 JITCompiler。
3、当Main方法第一次调用引用的类型的方法成员时,JITCompiler函数将被调用,该函数负责将一个方法的IL代码编译成本地CPU指令。
1、 JITCompiler将前面第2步的数据结构中的要调用的真实方法的地址替换成包含刚刚编译好的CPU指令的内存块地址。
2、 JITCompiler跳转到该内存块中的代码上,开始执行。
注意:一个类型的所有方法只会编译一次,当这个类型的方法又被调用时,将会使用之前已经编译过的代码,这样只有在首次调用时,才会产生性能损失。
也就是说托管代码跟非托管代码相比,性能上的损失是非常小的,近乎微不足道。
1 一个方法执行之前,CLR首先检测Main中代码引用的所有类型,CLR会分配一个内部的数据结构,该数据结构用于管理对所引用类型的访问。
2、当该数据结构被初始化时,CLR将把每一个条目设置 为CLR内部的一个没有正式记录的函数,我们暂且称该函数为 JITCompiler。
3、当Main方法第一次调用引用的类型的方法成员时,JITCompiler函数将被调用,该函数负责将一个方法的IL代码编译成本地CPU指令。
1、 JITCompiler将前面第2步的数据结构中的要调用的真实方法的地址替换成包含刚刚编译好的CPU指令的内存块地址。
2、 JITCompiler跳转到该内存块中的代码上,开始执行。
注意:一个类型的所有方法只会编译一次,当这个类型的方法又被调用时,将会使用之前已经编译过的代码,这样只有在首次调用时,才会产生性能损失。
也就是说托管代码跟非托管代码相比,性能上的损失是非常小的,近乎微不足道。
#34
缓存导致第二次快。
其实软件效率还是慢的。
其实软件效率还是慢的。
#35
顶者也。
#36
连接池,看似好深奥的问题!
#37
搞不懂,帮不上忙了.帮顶
#38
换机器
#39
和数据库连接的问题吧
#40
帮顶
#41
第一次运行会调用相关数据到内存,方便以后调用如静态方法等
5楼正解
5楼正解
#42
up
#43
#44
这个问题得看是什么软件了,也许逻辑有问题。
#45
问题多多,具体问题具体分析,路过,不说两句对不起楼主是吧。
#46
第一次编译都是这样的
#47
接分
#48
帮顶了!
#49
嘿嘿,不知道~~
#50
顶
#1
顶者有分
#2
第一次运行需要1秒钟,而第二次,200毫秒就搞定了--->这个很正常,中间码需要转本地码,第二次省略了转的过程,有缓存。
#3
接分,缓存的问题吧
#4
额,这个。
不怎么了解,顶下。
不怎么了解,顶下。
#5
第一次运行会调用相关数据到内存,方便以后调用如静态方法等
#6
自己测程序,比如在一些重要的业务过程,耗时方法等,用stopwatch计时,看这些方法处理数据的性能怎样,写日志记录下来,就知道了啊。
#7
主要是代码解析的问题。
#8
要用.net就得这样,把机器配置升一下,能快些
#9
顶了
#10
软件在长时间开着不使用(可能5-10分钟),然后过5-10分钟后,开始使用,速度会变慢,但是慢了一会,又会快起来,一直使用下去,速度就很快
--->这个问题怀疑与操作系统内存调度有关,长时间不用这个软件,其他进程的数据被刷进高速缓存页面,忽然开始使用时,会卡一下,如果软件占用内存多,卡的时间就长
--->这个问题怀疑与操作系统内存调度有关,长时间不用这个软件,其他进程的数据被刷进高速缓存页面,忽然开始使用时,会卡一下,如果软件占用内存多,卡的时间就长
#11
第一次开始的时候,系统需要配置一下环境,所以比较慢,第二次已经存在了一些必要条件,就快一点
.NET 在一段时间没有使用,会自动释放一些资源
.NET 在一段时间没有使用,会自动释放一些资源
#12
估计是正常的吧。
#13
帮顶,个人认为有必要重构一下代码,将通过一些算法优化一下线程,情况会好一些.
#14
我顶顶吧。
楼上的都说了。
楼上的都说了。
#15
同意楼上
其次:你线程是不是空闲时间占资源太多,见意在空闲时间用,Thread.Sleep(1000);空闲一秒钟
再次:你程序中写的静态变量是不是过多,所以会产生这样结果,静态变量是程序使用中一直加载在内存的,所以在你内存过小的情况下,会转存硬盘的扩充缓存
其次:你线程是不是空闲时间占资源太多,见意在空闲时间用,Thread.Sleep(1000);空闲一秒钟
再次:你程序中写的静态变量是不是过多,所以会产生这样结果,静态变量是程序使用中一直加载在内存的,所以在你内存过小的情况下,会转存硬盘的扩充缓存
#16
up
#17
帮顶吓.
#18
同意10楼
#19
先顶
#20
不懂
#21
楼上的都说很详细了,软件没有什么问题。
#22
接分.............
#23
应该是与操作系统有关吧,友情帮顶。
#24
缓存
#25
顶,不明真相的围观群众
#26
应该和缓存有关系。
#27
第一次打开慢是老问题了,然后再打开,应该就是缓存了。
#28
帮顶下~~
#29
顶
#30
这种状况,在有动态访问数据库的情况下,更为显示。
连接到数据库服务器是个费时的过程。必须建立物理通道(例如套接字或命名管道),必须与服务器进行初次连接,必须分析连接字符串信息,必须由服务器对连接进行身份验证,等等。
ADO.NET中,使用了连接池的优化方法,来管理维护连接。Open时,连接池就会检查池中是否有可用的连接。如果有,直接返回给调用者,而不是建新。 Close 时,会判断该连接是否在最小连接数之内,如果“是”会将连接回收到活动连接池中,而不是真正关闭。以备下次使用。
这样,第一次使用时比较慢,紧接着再用就很快。
如果,长期不用,超过连接的生命周期(有限时的),或着长期不用被连接池优化清理掉了。这就再用,那就和第一次一样,从头再来一遍,当然就慢了。
连接到数据库服务器是个费时的过程。必须建立物理通道(例如套接字或命名管道),必须与服务器进行初次连接,必须分析连接字符串信息,必须由服务器对连接进行身份验证,等等。
ADO.NET中,使用了连接池的优化方法,来管理维护连接。Open时,连接池就会检查池中是否有可用的连接。如果有,直接返回给调用者,而不是建新。 Close 时,会判断该连接是否在最小连接数之内,如果“是”会将连接回收到活动连接池中,而不是真正关闭。以备下次使用。
这样,第一次使用时比较慢,紧接着再用就很快。
如果,长期不用,超过连接的生命周期(有限时的),或着长期不用被连接池优化清理掉了。这就再用,那就和第一次一样,从头再来一遍,当然就慢了。
#31
缓存?
#32
up
#33
.net程序执行过程如下:
1 一个方法执行之前,CLR首先检测Main中代码引用的所有类型,CLR会分配一个内部的数据结构,该数据结构用于管理对所引用类型的访问。
2、当该数据结构被初始化时,CLR将把每一个条目设置 为CLR内部的一个没有正式记录的函数,我们暂且称该函数为 JITCompiler。
3、当Main方法第一次调用引用的类型的方法成员时,JITCompiler函数将被调用,该函数负责将一个方法的IL代码编译成本地CPU指令。
1、 JITCompiler将前面第2步的数据结构中的要调用的真实方法的地址替换成包含刚刚编译好的CPU指令的内存块地址。
2、 JITCompiler跳转到该内存块中的代码上,开始执行。
注意:一个类型的所有方法只会编译一次,当这个类型的方法又被调用时,将会使用之前已经编译过的代码,这样只有在首次调用时,才会产生性能损失。
也就是说托管代码跟非托管代码相比,性能上的损失是非常小的,近乎微不足道。
1 一个方法执行之前,CLR首先检测Main中代码引用的所有类型,CLR会分配一个内部的数据结构,该数据结构用于管理对所引用类型的访问。
2、当该数据结构被初始化时,CLR将把每一个条目设置 为CLR内部的一个没有正式记录的函数,我们暂且称该函数为 JITCompiler。
3、当Main方法第一次调用引用的类型的方法成员时,JITCompiler函数将被调用,该函数负责将一个方法的IL代码编译成本地CPU指令。
1、 JITCompiler将前面第2步的数据结构中的要调用的真实方法的地址替换成包含刚刚编译好的CPU指令的内存块地址。
2、 JITCompiler跳转到该内存块中的代码上,开始执行。
注意:一个类型的所有方法只会编译一次,当这个类型的方法又被调用时,将会使用之前已经编译过的代码,这样只有在首次调用时,才会产生性能损失。
也就是说托管代码跟非托管代码相比,性能上的损失是非常小的,近乎微不足道。
#34
缓存导致第二次快。
其实软件效率还是慢的。
其实软件效率还是慢的。
#35
顶者也。
#36
连接池,看似好深奥的问题!
#37
搞不懂,帮不上忙了.帮顶
#38
换机器
#39
和数据库连接的问题吧
#40
帮顶
#41
第一次运行会调用相关数据到内存,方便以后调用如静态方法等
5楼正解
5楼正解
#42
up
#43
#44
这个问题得看是什么软件了,也许逻辑有问题。
#45
问题多多,具体问题具体分析,路过,不说两句对不起楼主是吧。
#46
第一次编译都是这样的
#47
接分
#48
帮顶了!
#49
嘿嘿,不知道~~
#50
顶