I've noticed a few things:
1) The EG query wizard produces proc sql. Sometimes that seems slower than a data step for some kinds queries but some kinds of joins are best served through proc sql.
2)Since the query wizard uses proc sql, it doesn't require data sets to be sorted prior to running. data step requires sorting. If you sort the datasets, I would suspect similar run times.
Message was edited by: DBailey
I see lots of guessing. I suggest the OP provides us with some real-life cases so we can offer help. Otherwise we're in the dark. All comments are true in themselves but do not explain "pathetic" performance. EG is my daily tool and the increased productivity outweighs any performance penalty one might have in comparison to DMS / plain code. Nothing pathetic about EG.
But again, please stop providing answers when the question is not clear. For lucky shots there is plenty occasion at SGF11.
Sorry for appearing rude. Maybe I unintentionally sounded less civil (could be because I'm Dutch) but I was certainly trying to be helpful. It was my assesment that the OP could help us help him by providing more information. The adjective "pathetic" suggests there must be some powerful evidence yet to be disclosed.
Consider me the doctor that will not just try to prescribe some medicine before doing some q&a and poking in the sore spots. In a very civil fashion.
Ik verontschuldig me voor het lezen van te veel in je reactie. Ik ben het eens dat een aantal voorbeelden kunnen ons helpen om het opsporen van de OP's problemen. Alles is goed.
Message was edited by: DBailey
If you are accessing data from a remote server, and processing a query locally using SAS EG then SAS EG has to copy all the data to the local session before it can process it. Perhaps this is the problem.
How about exporting the code of a sample EG process which you have already benchmarked in EG, then run the exported code in base SAS? If it performs the same as in EG, then it is not the EG environment that is the issue but the code itself.
A comparison of techniques with your different base SAS code may provide the answers.
I don't know if these relate to this issue, but here are two scenarios that I have found result in very slow processing for EG users, don't really relate to SAS or EG, and are very easy to fall into for new users.
1. Moving large amounts of data between machines. This can be because EG submits code to a server that needs to access data on another server, or because EG runs the SAS session locally, and the local computer pulls data from a server. The SAS session is actually doing next to nothing, just ticking along waiting for the data communication.
To diagnose this, if you can use performance monitor look for very high network card volume. Another option is to move the data to the machine that the session will run on, and then run EG against it.
2. Running an EG descriptive task (e.g. Summary Statistics, Summary Tables, Table Analysis) with either a very large (tens of thousands to millions) number of combinations of classification variables, or using a variable with very high cardinality as a classification variable. SAS will actually run this very quickly, but if you're requesting results in one of the viewable formats, rendering the formatted document will take hours, and may never return. HTML is (I think) the worst.
To diagnose this, set the descriptive task to save the statistics to a dataset and turn off all of the viewable result formats. EG may run very quickly.