10 个解决方案
#1
devexpress本来就有慢的问题,但10几个控件不至于显示慢吧,慢的问题是不是在你的数据加载上
#2
我用StopWatch监控了一下,确实执行了一下InitializeComponent就花了500多ms,数据加载我全部改成异步了,在初始化的时候几乎不耗时
#3
慢正常啊,用它的splashmanager控件 搞一个进度条会好点。
#4
看一下你的字体有没有变,有的话换回来.
#5
只是第一次初始化会慢,第二次开始就快了很多,这个原理知道是啥不
#6
不清楚呀,清楚的话我都自己自定义控件,然后开源给大家。
#7
慢正常啊,用它的splashmanager控件 搞一个进度条会好点。
只是第一次初始化会慢,第二次开始就快了很多,这个原理知道是啥不
不清楚呀,清楚的话我都自己自定义控件,然后开源给大家。
没办法了,打算在登录的时候把慢的窗体先全部初始化一遍。
#8
有这个问题,我反正是能用异步都异步加载了,但是启动有时候还是要反应一下
#9
鱼跟熊掌不可得兼..
好看的代价肯定是牺牲了性能..任何控件都一样.
拿我们常用的easyui的一个button来说.
我用<asp:button 的性能是<a class=easyui-button的3倍,
因为后者生成了一大堆的html....
当然了这是web..dev在web上表现也是一样. 功能强大 UI漂亮..就是速度太慢了...
在CS上 也是一样的道理.
好看的代价肯定是牺牲了性能..任何控件都一样.
拿我们常用的easyui的一个button来说.
我用<asp:button 的性能是<a class=easyui-button的3倍,
因为后者生成了一大堆的html....
当然了这是web..dev在web上表现也是一样. 功能强大 UI漂亮..就是速度太慢了...
在CS上 也是一样的道理.
#10
同问。
其实我对你用Stopwatch测试InitializeComponent方法的结果深表怀疑,是不是你测试方法上有漏洞。
我原来也是认为慢的原因是InitializeComponent的方法上,所以我也使用Stopwatch测试过,我是明确的把Stopwatch的Start和Stop就放在InitializeComponent方法的前后,中间就一句话InitializeComponent(),结果是执行InitializeComponent()实际上非常快,它实际上就是new dev对象,不会慢,我原来以为dev的组件,论继承,有十几层,那当然慢,但测试结果并不是这样,一般几十毫秒也就执行完了。
那如果不是InitializeComponent慢,那哪里慢呢?我只能猜测是:
1、加载dev相关的dll慢,而这个慢是查不出来的,因为winform似乎没开放dll加载的事件,能让我们了解加载的快慢。
2、显示慢,这个也是winform无法测试的,InitializeComponent很快,Form_load也快,但tmd显示出来就是慢,我只能猜测是dev的UI渲染很吃显存?电脑因为显存不足,所以渲染慢?
反正都是瞎猜。
其实我对你用Stopwatch测试InitializeComponent方法的结果深表怀疑,是不是你测试方法上有漏洞。
我原来也是认为慢的原因是InitializeComponent的方法上,所以我也使用Stopwatch测试过,我是明确的把Stopwatch的Start和Stop就放在InitializeComponent方法的前后,中间就一句话InitializeComponent(),结果是执行InitializeComponent()实际上非常快,它实际上就是new dev对象,不会慢,我原来以为dev的组件,论继承,有十几层,那当然慢,但测试结果并不是这样,一般几十毫秒也就执行完了。
那如果不是InitializeComponent慢,那哪里慢呢?我只能猜测是:
1、加载dev相关的dll慢,而这个慢是查不出来的,因为winform似乎没开放dll加载的事件,能让我们了解加载的快慢。
2、显示慢,这个也是winform无法测试的,InitializeComponent很快,Form_load也快,但tmd显示出来就是慢,我只能猜测是dev的UI渲染很吃显存?电脑因为显存不足,所以渲染慢?
反正都是瞎猜。
#1
devexpress本来就有慢的问题,但10几个控件不至于显示慢吧,慢的问题是不是在你的数据加载上
#2
devexpress本来就有慢的问题,但10几个控件不至于显示慢吧,慢的问题是不是在你的数据加载上
#3
慢正常啊,用它的splashmanager控件 搞一个进度条会好点。
#4
看一下你的字体有没有变,有的话换回来.
#5
慢正常啊,用它的splashmanager控件 搞一个进度条会好点。
只是第一次初始化会慢,第二次开始就快了很多,这个原理知道是啥不
#6
慢正常啊,用它的splashmanager控件 搞一个进度条会好点。
只是第一次初始化会慢,第二次开始就快了很多,这个原理知道是啥不
不清楚呀,清楚的话我都自己自定义控件,然后开源给大家。
#7
慢正常啊,用它的splashmanager控件 搞一个进度条会好点。
只是第一次初始化会慢,第二次开始就快了很多,这个原理知道是啥不
不清楚呀,清楚的话我都自己自定义控件,然后开源给大家。
没办法了,打算在登录的时候把慢的窗体先全部初始化一遍。
#8
有这个问题,我反正是能用异步都异步加载了,但是启动有时候还是要反应一下
#9
鱼跟熊掌不可得兼..
好看的代价肯定是牺牲了性能..任何控件都一样.
拿我们常用的easyui的一个button来说.
我用<asp:button 的性能是<a class=easyui-button的3倍,
因为后者生成了一大堆的html....
当然了这是web..dev在web上表现也是一样. 功能强大 UI漂亮..就是速度太慢了...
在CS上 也是一样的道理.
好看的代价肯定是牺牲了性能..任何控件都一样.
拿我们常用的easyui的一个button来说.
我用<asp:button 的性能是<a class=easyui-button的3倍,
因为后者生成了一大堆的html....
当然了这是web..dev在web上表现也是一样. 功能强大 UI漂亮..就是速度太慢了...
在CS上 也是一样的道理.
#10
同问。
其实我对你用Stopwatch测试InitializeComponent方法的结果深表怀疑,是不是你测试方法上有漏洞。
我原来也是认为慢的原因是InitializeComponent的方法上,所以我也使用Stopwatch测试过,我是明确的把Stopwatch的Start和Stop就放在InitializeComponent方法的前后,中间就一句话InitializeComponent(),结果是执行InitializeComponent()实际上非常快,它实际上就是new dev对象,不会慢,我原来以为dev的组件,论继承,有十几层,那当然慢,但测试结果并不是这样,一般几十毫秒也就执行完了。
那如果不是InitializeComponent慢,那哪里慢呢?我只能猜测是:
1、加载dev相关的dll慢,而这个慢是查不出来的,因为winform似乎没开放dll加载的事件,能让我们了解加载的快慢。
2、显示慢,这个也是winform无法测试的,InitializeComponent很快,Form_load也快,但tmd显示出来就是慢,我只能猜测是dev的UI渲染很吃显存?电脑因为显存不足,所以渲染慢?
反正都是瞎猜。
其实我对你用Stopwatch测试InitializeComponent方法的结果深表怀疑,是不是你测试方法上有漏洞。
我原来也是认为慢的原因是InitializeComponent的方法上,所以我也使用Stopwatch测试过,我是明确的把Stopwatch的Start和Stop就放在InitializeComponent方法的前后,中间就一句话InitializeComponent(),结果是执行InitializeComponent()实际上非常快,它实际上就是new dev对象,不会慢,我原来以为dev的组件,论继承,有十几层,那当然慢,但测试结果并不是这样,一般几十毫秒也就执行完了。
那如果不是InitializeComponent慢,那哪里慢呢?我只能猜测是:
1、加载dev相关的dll慢,而这个慢是查不出来的,因为winform似乎没开放dll加载的事件,能让我们了解加载的快慢。
2、显示慢,这个也是winform无法测试的,InitializeComponent很快,Form_load也快,但tmd显示出来就是慢,我只能猜测是dev的UI渲染很吃显存?电脑因为显存不足,所以渲染慢?
反正都是瞎猜。