LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (May 2000, week 4)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 23 May 2000 10:48:01 -0400
Reply-To:     WHITLOI1 <WHITLOI1@WESTAT.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         WHITLOI1 <WHITLOI1@WESTAT.COM>
Subject:      Re: Macro Problem On Input
Comments: To: Kurt Beckman <kurt_beckman@EARTHLINK.NET>,
          frank.mwaniki@PHARMA.NOVARTIS.COM
Content-Type: text/plain; charset=US-ASCII

Subject: Re: Macro Problem On Input Summary: Test it. Respondent: Ian Whitlock <whitloi1@westat.com>

In response to a question about macro and an INPUT statement Kurt Beckman <kurt_beckman@EARTHLINK.NET> responded.

> On 22 May 00 22:48:34 GMT, frank.mwaniki@PHARMA.NOVARTIS.COM > (<Frank Mwaniki>) wrote: > > >..... > > > > INPUT > > @ 014 %DO I = 1 %TO 27; > > CAPN&I 3. > > %END; > > @; > > INPUT > > @ 095 %DO I = 1 %TO 27; > > XGXN&I 3. > > %END; > > @; > > etc.... > > I try to avoid using macro language to do something that can be > done in open code. If you are reading a large amount of data, > the difference between this solution and one done with open code > can be significant.

In general remarks like the above should include some form of quantification and statement of systems information for which the claim is made.

I decided to test the claim on a PC running Windows 95 SAS V8 TS1M0. In general, I agree with the statement - avoid macro when it is easy to avoid. However, I agree because of the issue of code clarity, not execution efficiency. If it were my task, I would probably have used Jack Hamilton's <JackHamilton@FIRSTHEALTH.COM> suggestion (had it occurred to me).

> input @1 area $char6. > @7 id $char7. > @14 (capn1-capn27) (3.) > @95 (xgxn1-xgxn27) (3.) ...

To me the execution efficiency issues are

1) What does it cost to use trailing @'s? 2) What does it cost to use a well designed macro? 3) What does it cost to use PL1 edit style input?

To find out I ran the following program

filename q "c:\junk\test.dat" ;

data _null_ ; out = repeat ( "12345" , 19 ) ; file q ; do i = 1 to 200000 ; put i z10. out ; end ; run ;

%macro getvars ( dummy ) ;

%local i ; input id $char10. @ ; %do i = 1 %to 100 ; input x&i 1. @ ; %end ;

%mend getvars ;

%macro vlist ( dummy ) ;

%local i ; id $char10. %do i = 1 %to 100 ; x&i 1. %end ;

%mend vlist ;

data w ; infile q truncover obs = 10 ; %getvars () run ;

data w ; infile q truncover ; %getvars () run ;

proc datasets lib = work nolist ; delete w ; quit ;

data w2 ; infile q truncover obs = 10 ; input %vlist ; run ;

data w2 ; infile q truncover ; input %vlist ; run ;

proc datasets lib = work nolist ; delete w2 ; quit ;

data w3 ; infile q truncover obs = 10 ; input id $char10. (x1-x100) (1.) ; run ;

data w3 ; infile q truncover ; input id $char5. (x1-x100) (1.) ; run ;

proc datasets lib = work nolist ; delete w3 ; quit ;

Note that each INPUT data step is preceded by the same code reading 10 observations, since I wanted to eliminate the noise created by the previous step.

Here are the results for two executions.

Macro with 100 trailing @'s 1:28.65 1:28.10 Macro well designed 1:01.22 1:01.12 Pl1 edit style no macro 1.01.18 1:00.59

It appears that the claim to avoid trailing @'s has some validity at least when you generate 100 of them. However the claim that one should avoid macro to save execution time appears to hold little merit in this case.

Ian Whitlock


Back to: Top of message | Previous page | Main SAS-L page