同一个DLL，在两个程序中的处理速度差别很大，求助

时间：2023-02-04 19:25:01
此DLL专门用来处理数据的，比如在第一个程序中，处理时间为80s；在第二个程序中，处理时间为110s；随着数据量的增加，时间差异会加大。
是什么原因？求助啊

19 个解决方案

#1

进程处理性能也可能影响，它占用的内存，CPU等，它自己干的其他工作等

#2

主要看资源请求和线程同步等有没有受到影响

#3

引用 2 楼 bragi523 的回复:
主要看资源请求和线程同步等有没有受到影响

DLL是在线程中使用的，可有什么问题？

#4

引用 1 楼 oyljerry 的回复:
进程处理性能也可能影响，它占用的内存，CPU等，它自己干的其他工作等

程序没干别的了，就调用DLL处理数据，在一个线程中处理的

#5

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

#6

引用 5 楼 worldy 的回复:
你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据

#7

引用 6 楼 rmaly 的回复:
Quote: 引用 5 楼 worldy 的回复:

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据


两个程序的代码完全相同？

#8

两个程序都是创建一个线程，然后加载DLL进行数据处理，代码是一样的

#9

引用 7 楼 worldy 的回复:
Quote: 引用 6 楼 rmaly 的回复:

Quote: 引用 5 楼 worldy 的回复:

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据


两个程序的代码完全相同？

两个程序都是创建一个线程，然后加载DLL进行数据处理，代码是一样的

#10

求助求助 同一个DLL，在两个程序中的处理速度差别很大，求助

#11

处理的 是什么？记录集？

#12

引用 11 楼 worldy 的回复:
处理的 是什么？记录集？

这个跟问题没关吧，好纠结啊

#13

引用 9 楼 rmaly 的回复:
Quote: 引用 7 楼 worldy 的回复:

Quote: 引用 6 楼 rmaly 的回复:

Quote: 引用 5 楼 worldy 的回复:

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据


两个程序的代码完全相同？

两个程序都是创建一个线程，然后加载DLL进行数据处理，代码是一样的

看一下两者CPU占用时间等是否相同，应该还是调度等区别

#14

是要从 CPU 占用率和 DLL 执行所需要的时间来分析。

可以考虑将 CPU 使用率和 DLL 执行数据处理的 TickCount 打印出来分析。

#15

该回复于2013-10-25 09:42:15被管理员删除

#16

两个程序中DLL的基地址是否一致排除地址冲突而导到的加载延迟。
1.常规做法，打log。
2.高级方法
用vmmap看一下资源占用情况。
xperf测试性能。
把链接选项的profile打开，用VS2010或以上的性能监视工具Check一下。

#17

引用 16 楼 ysjyniiq 的回复:
两个程序中DLL的基地址是否一致排除地址冲突而导到的加载延迟。
1.常规做法，打log。
2.高级方法
用vmmap看一下资源占用情况。
xperf测试性能。
把链接选项的profile打开，用VS2010或以上的性能监视工具Check一下。

可以说一个解决这个问题的方法吗？

#18

既然你想现成的，就像14楼说那样，用GetTickCount在你代码关键的方计算一下消耗的时间。两个程序比较一下，逐渐缩小范围。

#19

该回复于2013-11-04 20:25:14被管理员删除

#20

#1

进程处理性能也可能影响，它占用的内存，CPU等，它自己干的其他工作等

#2

主要看资源请求和线程同步等有没有受到影响

#3

引用 2 楼 bragi523 的回复:
主要看资源请求和线程同步等有没有受到影响

DLL是在线程中使用的，可有什么问题？

#4

引用 1 楼 oyljerry 的回复:
进程处理性能也可能影响，它占用的内存，CPU等，它自己干的其他工作等

程序没干别的了，就调用DLL处理数据，在一个线程中处理的

#5

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

#6

引用 5 楼 worldy 的回复:
你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据

#7

引用 6 楼 rmaly 的回复:
Quote: 引用 5 楼 worldy 的回复:

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据


两个程序的代码完全相同？

#8

两个程序都是创建一个线程，然后加载DLL进行数据处理，代码是一样的

#9

引用 7 楼 worldy 的回复:
Quote: 引用 6 楼 rmaly 的回复:

Quote: 引用 5 楼 worldy 的回复:

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据


两个程序的代码完全相同？

两个程序都是创建一个线程，然后加载DLL进行数据处理，代码是一样的

#10

求助求助 同一个DLL，在两个程序中的处理速度差别很大，求助

#11

处理的 是什么？记录集？

#12

引用 11 楼 worldy 的回复:
处理的 是什么？记录集？

这个跟问题没关吧，好纠结啊

#13

引用 9 楼 rmaly 的回复:
Quote: 引用 7 楼 worldy 的回复:

Quote: 引用 6 楼 rmaly 的回复:

Quote: 引用 5 楼 worldy 的回复:

你确定是dll引起的时间差异？也许是调用者本身有问题

另外，dll反应出来的速度差别应该是来源判断分支，调用者的数据如果让dll处理进入耗时长的分支，则耗时必然时间会比较长

两者处理同一份数据


两个程序的代码完全相同？

两个程序都是创建一个线程，然后加载DLL进行数据处理，代码是一样的

看一下两者CPU占用时间等是否相同，应该还是调度等区别

#14

是要从 CPU 占用率和 DLL 执行所需要的时间来分析。

可以考虑将 CPU 使用率和 DLL 执行数据处理的 TickCount 打印出来分析。

#15

该回复于2013-10-25 09:42:15被管理员删除

#16

两个程序中DLL的基地址是否一致排除地址冲突而导到的加载延迟。
1.常规做法，打log。
2.高级方法
用vmmap看一下资源占用情况。
xperf测试性能。
把链接选项的profile打开，用VS2010或以上的性能监视工具Check一下。

#17

引用 16 楼 ysjyniiq 的回复:
两个程序中DLL的基地址是否一致排除地址冲突而导到的加载延迟。
1.常规做法，打log。
2.高级方法
用vmmap看一下资源占用情况。
xperf测试性能。
把链接选项的profile打开，用VS2010或以上的性能监视工具Check一下。

可以说一个解决这个问题的方法吗？

#18

既然你想现成的，就像14楼说那样，用GetTickCount在你代码关键的方计算一下消耗的时间。两个程序比较一下，逐渐缩小范围。

#19

该回复于2013-11-04 20:25:14被管理员删除

#20

标签：

相关文章