楼主: yzzhang
2951 18

[原创博文] 这样两种写法运行效率差别大吗? [推广有奖]

  • 1关注
  • 0粉丝

已卖:93份资源

博士生

52%

还不是VIP/贵宾

-

威望
0
论坛币
1979 个
通用积分
2.9500
学术水平
2 点
热心指数
1 点
信用等级
0 点
经验
569 点
帖子
116
精华
0
在线时间
459 小时
注册时间
2009-2-17
最后登录
2025-12-15

楼主
yzzhang 发表于 2010-5-7 20:50:07 |AI写论文

+2 论坛币
k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群
赵安豆老师微信:zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

感谢您参与论坛问题回答

经管之家送您两个论坛币!

+2 论坛币
有一数据表,表名:table   字段:x1,x2,……,x200    记录数:1亿
data a(keep=x1);
     set table(keep=x1 where=(x1>100));
run;
data b;
     set table;
     where x1>100;
     keep x1;
run;
两种写法的效率一样吗?

个人意见,望指正和讨论;
个人认为两种写法效率应该一样。
表a:
      编译时,sas识别出程序涉及到的变量只有x1,  因此只读入x1字段值 并在读入时用where条件筛选;
表b:
     碰到run语句后,进行编译,程序中涉及到的变量只有 x1 因此读table时也只会读这个字段而忽略别的字段;在写入时判断where条件。
     由于不管读入时判断还是写时判断,都要对x1先读取,再考虑到是逐条记录读取和输出,因此where影响不存在。
二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝

关键词:Where Table HERE ABLE keep 数据表 where 程序

回帖推荐

crackman 发表于2楼  查看完整内容

个人认为第一个效率要高于第二个效率 因为第一个程序 一开始就对table数据集进行了一次洗刷,然后在进行SET读取 a里面 第二个程序 则是一开始全部读取table里面的数据,然后在进行洗刷 等于咱们做事的风格一样 第一个程序就像 咱们选选择对象了 在开始干活吧,这样做事有针对性,效率高 第二程序就像 咱们先不去想要谁还是不要谁的问题,先干活,全部要了,然后慢慢来剔除不需要的,做事盲目,没有效率

yatming 发表于16楼  查看完整内容

15# nkwilling 我再来补充一下。 keep=放在括号里面并不一定比放在外面效率高,要分情况来看。 其实keep=的data set option也要分两种情况: 1.KEEP= on SET statement 2.KEEP= on DATA statement data step的运行机制用the little sas book的经典的话就是line by line,所以KEEP= on DATA statement这个情况其实和keep statement(即keep放在外面)的效率是相似的,是对于在pdv中的每条observation都要做keep计算,和buf ...
已有 1 人评分热心指数 收起 理由
crackman + 1 有意思

总评分: 热心指数 + 1   查看全部评分

本帖被以下文库推荐

沙发
crackman 发表于 2010-5-7 21:13:16
个人认为第一个效率要高于第二个效率
因为第一个程序 一开始就对table数据集进行了一次洗刷,然后在进行SET读取 a里面
第二个程序 则是一开始全部读取table里面的数据,然后在进行洗刷

等于咱们做事的风格一样
第一个程序就像 咱们选选择对象了 在开始干活吧,这样做事有针对性,效率高
第二程序就像 咱们先不去想要谁还是不要谁的问题,先干活,全部要了,然后慢慢来剔除不需要的,做事盲目,没有效率

藤椅
crackman 发表于 2010-5-7 21:13:57
个人认为第一个效率要高于第二个效率
因为第一个程序 一开始就对table数据集进行了一次洗刷,然后在进行SET读取 a里面
第二个程序 则是一开始全部读取table里面的数据,然后在进行洗刷

等于咱们做事的风格一样
第一个程序就像 咱们选选择对象了 在开始干活吧,这样做事有针对性,效率高
第二程序就像 咱们先不去想要谁还是不要谁的问题,先干活,全部要了,然后慢慢来剔除不需要的,做事盲目,没有效率

板凳
yzzhang 发表于 2010-5-7 21:19:58
但是我按两种方法在eg上测试了下,两者的cpu时间几本上没有差别
测试的数据有几十字段,只处理一个字段,记录数在千万左右;
cpu时间分别是
a方法8:08.70
b方法8:02.76  
貌似后者还快点,两次都是后者稍快点,所以才产生疑问;

个人认为碰到run语句代码编译完毕,在读入时,sas会自动忽略不读在整个程序中没有出现的变量。

报纸
crackman 发表于 2010-5-7 21:24:16
我也是百万级的数据
测试了两遍
不稳定 感觉所需要的时间

地板
yzzhang 发表于 2010-5-7 21:31:00
你测试的两种方法的cpu时间差别大吗?

我以前也是和你一样认为,但测试后发现不明显,自己猜想sas也不会那么笨去读一些用不到的东西浪费时间

7
crackman 发表于 2010-5-7 21:33:26
NOTE: 有 1365380 个从数据集 TMP1.TEMP4 读取的观测。
      WHERE year>2005;
NOTE: 数据集 WORK.B 有 1365380 个观测和 1 个变量。
NOTE: “DATA 语句”所用时间(总处理时间):
      实际时间          2.35 秒
      CPU 时间          1.06 秒

NOTE: 有 1365380 个从数据集 TMP1.TEMP4 读取的观测。
      WHERE year>2005;
NOTE: 数据集 WORK.A 有 1365380 个观测和 1 个变量。
NOTE: “DATA 语句”所用时间(总处理时间):
      实际时间          1.96 秒
      CPU 时间          1.04 秒

8
yzzhang 发表于 2010-5-7 21:36:34
多谢版主的热心,我再试下去,^_^

9
yzzhang 发表于 2010-5-7 23:11:34
15         data a1;
16         set table(keep=x);
17         run;

NOTE: 从数据集 WORK.TABLE 读取了 5548572 个观测。
NOTE: 数据集 WORK.A1 有 5548572 个观测和 1 个变量。
NOTE: “DATA 语句”所用时间(总处理时间):
      实际时间         7.14 秒
      CPU 时间         6.98 秒
      

18         data b1;
19         set table;
20         keep x;
21         run;

NOTE: “DATA 语句”所用时间(总处理时间):
      实际时间         43.40 秒
      CPU 时间         6.70 秒
      
NOTE: 从数据集 WORK.TABLE 读取了 5548572 个观测。
NOTE: 数据集 WORK.B1 有 5548572 个观测和 1 个变量。
只有keep语句时,实际时间前一种方法明显较后一种方法快,cpu时间差不多。

22         
23         data a2;
24         set table(keep=x where=(x='0000497604'));
25         run;

NOTE: “DATA 语句”所用时间(总处理时间):
      实际时间         45.79 秒
      CPU 时间         4.09 秒
      
NOTE: 从数据集 WORK.TABLE 读取了 2 个观测。
      WHERE x='0000497604';
NOTE: 数据集 WORK.A2 有 2 个观测和 1 个变量。

26         data b2;
27         set table;
28         keep x;
29         where x='0000497604';
30         run;

NOTE: “DATA 语句”所用时间(总处理时间):
      实际时间         44.18 秒
      CPU 时间         3.95 秒
      
NOTE: 从数据集 WORK.TABLE 读取了 2 个观测。
      WHERE x='0000497604';
NOTE: 数据集 WORK.B2 有 2 个观测和 1 个变量。
keep语句和where语句一起时,相反后一种方法较快


自己有点糊涂了,高手指点了!

10
二马论道 发表于 2010-5-7 23:16:43
哎,有些看不懂啊 ,呜呜

您需要登录后才可以回帖 登录 | 我要注册

本版微信群
加好友,备注cda
拉您进交流群
GMT+8, 2025-12-27 03:22