Question

尝试测量两组小数据的性能，以确定更大的数据集对的有效执行方法。

*此测试是在具有32个观测值的数据集和具有37个观测值的数据集上完成的。

两种方法都给我相同的结果，处理时间略有不同。我有一个简单的数据步骤：

data check;
merge d1(in=a) d2(in=b);
by ssn;
if a=0 and b=1;
run;

数据步骤方法（第1次执行）日志产生以下内容 -

NOTE: There were 32 observations read from the data set WORK.D1.
NOTE: There were 37 observations read from the data set WORK.D2.
NOTE: The data set WORK.CHECK has 5 observations and 1 variables.
NOTE: DATA statement used (Total process time):
      real time           0.01 seconds
      cpu time            0.01 seconds

Proc SQL方法（在我们的特定情况下不存在查询）位于 -

之下

proc sql;
create table chck2 as
select b.* from d2 b
where not exists (select a.* from d1 a
                  where a.ssn=b.ssn)
;
quit;

sql proc在日志中打印以下内容 -

NOTE: PROCEDURE SQL used (Total process time):
      real time           0.04 seconds
      cpu time            0.03 seconds

这些方法都产生相同的结果，创建了相同5个人的最终数据集。虽然数据步骤处理看起来更快（即使只是几分之一秒），但这些性能结果总是适用吗？数据步骤方法总是会赢吗？这里有哪些关键影响因素？按特定顺序列出表格是否起作用，或者SAS会同时扫描两个表格吗？

仅供参考 - 我提到过（第一次执行），因为我从上面的实验和一般曝光中注意到，如果您随后处理数据步骤，SAS将比原始执行更快地处理后续步骤。假设这与SAS在以前执行的步骤中有内存有关...？

Answer 1

您永远不会从小型数据集中找到有意义的性能评估。开销将不可避免地打击任何实际的性能差异。 PROC SQL在调用过程（几百分之一秒）时涉及一些开销，这超过了总执行时间。使用足够大的数据集来运行测试，运行需要几分钟 - 通常在测试之间取得适当的平衡需要花费太长时间，合法的差异会被开销/随机性压缩。

更快的是：如果对数据集进行排序，并且SAS知道它已经排序，那么两个过程将处于相同的时间范围内的几率非常高。数据步合并非常快，SQL合并也是如此。

如果它没有排序，SQL可能（可能）会选择将where-exists转换为散列连接，这比排序大型数据集要快得多。当然，这需要数据集适合内存。在数据步骤中排序然后合并可能与SQL相同，或者它可能更慢 - 甚至更快，但我怀疑如果它首先需要排序通常不会更快。如果需要（散列或格式），数据步骤中的解决方案比排序/合并更快。

至于PROC SQL陈述的顺序是什么;如果SQL能够弄清楚你正在做什么并对其进行优化，那么它几乎无关紧要。但是，可能因为SQL可能不容易看到最佳路径，所以一个订单（通常是大数据集作为主要数据集，较小的数据集作为子查询）可能有助于SQL找出正确的方法更多比另一个容易。

而且 - SAS更快地执行第二次或更晚的运行的原因是您的操作系统（或可能是您的文件系统）正在缓存读取，因此它不必从磁盘重新读取SET文件。

SAS Proc SQL不存在查询与数据步骤a = 1 b = 0

1 个答案: