That's strange. under normal circumstances placeholders are much more efficient, especially if you reuse the statement handle returned by $dbh->prepare() and run the query many times. Do you have any links to this problem?

In case you need to use $dbh->quote() it's possible to use Interpolation to make the syntax nicer:

use Interpolation "'" => sub {"'".$dbh->quote($_[0])};
#...
$sql = qq{
  declare \@usrid int, \@sysusrid int
  select \@sysusrid = suser_id($'{$usrname}')
  select \@usrid = $IDVALUE from $ID
  where $IDNAME = 'USR_ID'

  insert into APPUSR (APP_CD, USR_ID, USRNAME, 
   USRFNAME, USRLNAME, FNCGRP_CD, SYSUSR_ID)
  values ('A', \@usrid, $'{$usrname}', 
   $'{$first}', $'{$full_last}', $fncgrp, \@sysusrid)
};
[download]

The DBD::Sybase docs:

DBD::Sybase supports the use of ? placeholders in SQL statements as long as the underlying library and database engine supports it. It does this by using what Sybase calls Dynamic SQL. ... When you use ? placeholders Sybase goes and creates a temporary stored procedure that corresponds to your SQL statement. You then pass variables to $sth->execute or $dbh->do, which get inserted in the query, and any rows are returned.

OpenClient creates stored procedures in tempdb for each prepare() call that includes ? placeholders. Creating these objects requires updating system tables in the tempdb database, and can therefore create a performance hotspot if a lot of prepare() statements from multiple clients are executed simultaneously. This problem has been corrected for Sybase 11.9.x and later servers, as they create "lightweight" temporary stored procs which are held in the server memory cache and don't affect the system tables at all.

...

In general however I find that if your application is going to run against Sybase it is better to write ad-hoc stored procedures rather than use the ? placeholders in embedded SQL.

Out of curiosity I did some simple timings to see what the overhead of doing a prepare with ? placehoders is vs. a straight SQL prepare and vs. a stored procedure prepare. Against an 11.0.3.3 server (linux) the placeholder prepare is significantly slower, and you need to do ~30 execute() calls on the prepared statement to make up for the overhead. Against a 12.0 server (solaris) however the situation was very different, with placeholder prepare() calls slightly faster than straight SQL prepare(). This is something that I really don't understand, but the numbers were pretty clear.

In all cases stored proc prepare() calls were clearly faster, and consistently so.

Ok, so that's a hefty quote from the online docs. Go read them yourself.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Please keep in mind that the versions of ASE that I refer to are all quite old. 11.0.3.3 is from the mid 90s, 12.0 is from 2000 or so. Current versions are 12.5.4 and 15.0.x, and for both of those placeholders are quite efficient.

I guess the docs should probably be updated...

Michael