Just look at the start of the macro code (as downloaded from https://support.sas.com/kb/24/addl/fusion24805_1_squeeze2.html), it contains a description and a short usage example:
%macro SQUEEZE( DSNIN /* name of input SAS dataset */
, DSNOUT /* name of output SAS dataset */
) ;
/* PURPOSE: create SAS dataset &DSNOUT using LENGTH */
/* statement for numeric vars that optimizes the */
/* variable to the fewest # of bytes needed */
/* to maintain the accuracy of the values */
/* contained in the variable */
/* */
/* macro variable SQZLENTH is created which is */
/* then invoked in a subsequent data step */
/* */
/* NOTE: only numeric variables are processed */
/* */
/* EXAMPLE OF USE: */
/* %SQUEEZE( DSNIN, DSNOUT ) */
If you are talking about another macro, please post the top lines of the code, and/or the URL from where you got it.
Just look at the start of the macro code (as downloaded from https://support.sas.com/kb/24/addl/fusion24805_1_squeeze2.html), it contains a description and a short usage example:
%macro SQUEEZE( DSNIN /* name of input SAS dataset */
, DSNOUT /* name of output SAS dataset */
) ;
/* PURPOSE: create SAS dataset &DSNOUT using LENGTH */
/* statement for numeric vars that optimizes the */
/* variable to the fewest # of bytes needed */
/* to maintain the accuracy of the values */
/* contained in the variable */
/* */
/* macro variable SQZLENTH is created which is */
/* then invoked in a subsequent data step */
/* */
/* NOTE: only numeric variables are processed */
/* */
/* EXAMPLE OF USE: */
/* %SQUEEZE( DSNIN, DSNOUT ) */
If you are talking about another macro, please post the top lines of the code, and/or the URL from where you got it.
The squeeze macro determines the max number of bytes required to store numerical values without loosing precision. The need to use such a macro is imho a very special and rather rare use case.
One would normally say: Know your data and define your columns lengths upfront as required. The "waste" is in the huge majority of cases with character variables and not with numerical ones. Changing the lengths of numerical variables is something you should be doing as an exception and only when you know exactly what you're doing and why.
If you've got performance issues then first thing to do is to run your code with options fullstimer; set. Then investigate the log to identify the longest running steps and spend your time tweaking these steps. Also worth is to examine your whole program and determine if you can optimize the flow by reducing passes through the data (=less data and proc steps) and reduce times you sort the data (SQL does a lot of implicit sorting). ....but where to look first should really be driven by identifying the longest running steps. You get often 80% of gain with 20% of effort just by tweaking the few most inefficient steps.
Just to add to @Patrick 's comment:
Nowadays, when I inspect long-running programs (long-running in the context of our batch jobs means more than 5 minutes), I first look for steps that do a "lookup" (like finding the location of an insurance agent by sorting by agent code and joining with the agents table), where the sorts and joins can be replaced by using a hash object in a step that does other things. This alone had me cut down the overall execution time to a quarter in some places.
Good news: We've extended SAS Hackathon registration until Sept. 12, so you still have time to be part of our biggest event yet – our five-year anniversary!
Check out this tutorial series to learn how to build your own steps in SAS Studio.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.