Prepared statement vs. Stored Procedure with RefCursor

I've been calling Oracle stored procedures that return RefCursors in my C# application. A sample stored procedure is given below.

CREATE OR REPLACE
PROCEDURE "DOSOMETHING"(
    P_RECORDS OUT SYS_REFCURSOR)
AS
BEGIN
    OPEN P_RECORDS FOR
    SELECT SOMETHING FROM SOMETABLE;
END;

When using the OracleDataReader to read the results for this, everytime the procedure is called the database parses the procedure. After quite a bit of searching I found out that eliminating this parse call is impossible with .NET when using RefCursor.

However if I just call the procedure using a 开发者_Python百科prepared statement as below, this parse call can be avoided.

public void DoSomething()
{
    var command = ServerDataConnection.CreateCommand();
    command.CommandType = CommandType.Text;
    command.CommandText = "SELECT SOMETHING FROM SOMETABLE";
    command.Prepare();

    using (var reader = command.ExecuteReader())
    {
        while (reader.Read())
        {
            DoSomethingToResult();
        }
    }
}

My question is which of these methods will have a minimum performance impact? Will changing the procedures to prepared statements to avoid parse calls have an even more negative impact on the application performance?

Please note that these select statements can return a large set of results. Possibly thousands of rows.

Using a ref cursor in PL/SQL will provoke a parse call each time the cursor is opened. The same parse call will be issued each time you call command.Prepare(). As it is now, your .NET code would parse the query as much as the PL/SQL code.

You could reuse your command object without additional parse calls if you need to issue the exact same query (with just a change in parameters). However, those parses would be soft parses so the performance may not be noticeable (most of the work is done in the hard parse, the first time the database encounters a query). Since your query returns lots of rows, the amount of work involved in a soft parse is certainly negligible compared to the amount of work to actually fetch those rows.