Datapump: expdp taking considerably longer than exp

Question

does anyone know why datapump export takes considerably longer than the deprecated exp function of oracle?
with few schemes datapump is rather fast. the more schemes you have, the longer it takes for datapump to perform an export. the deprecated exp function however remains fast.
some statistics i've made:
12 schemes: export takes ~30 seconds
128 schemes: export takes ~60 seconds
152 schemes: export takes ~80 seconds
328 schemes: export takes ~ 5minutes(!)
after i deleted schemes and reduced the number of schemes to 68, the expdp function became fast again: ~60 seconds.
does anyone have a hint for me about where i can make performance modifications? oracle describes in its documentation that datapump is faster than the deprecated export and that the deprecated exp function shouldn't be used anymore. currently this isn't true and we are at a big disadvantage now, since we are using datapump.
the expdp function "hangs" very long with the following logging output:
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
our oracle version: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
Edited by: user8995776 on Dec 18, 2010 8:29 AM

Answer 1

i want to add: i checked the trace files and it seems like i'm stuck with the same problem like this guy:
http://www.freelists.org/post/oracle-l/Any-valid-security-concerns-using-Data-Pump-over-conventional-expimp,7
this query takes very long, it's exactly the same as his:
>
select /*+rule*/
sys_xmlgen(value(ku$), xmlformat.createformat2('TABLE_DATA_T', '7')),
0, ku$.base_obj.name, ku$.base_obj.owner_name, 'TABLE',
to_char(ku$.bytes_alloc), to_char(ku$.et_parallel), ku$.fgac,
ku$.nonscoped_ref, ku$.xmlschemacols, ku$.name, ku$.name, 'TABLE_DATA',
ku$.part_name, ku$.parttype, ku$.property, ku$.refpar_level,
ku$.schema_obj.owner_name, ku$.ts_name, ku$.schema_obj.name,
ku$.trigflag,
decode(
ku$.schema_obj.type_num,
2, decode(
bitand(ku$.property, 8224),
8224, 'NESTED PARTITION',
8192, 'NESTED TABLE',
'TABLE'
19, decode(
bitand(ku$.property, 8224),
8224, 'NESTED PARTITION',
'PARTITION'
20, 'PARTITION',
'SUBPARTITION'
to_char(ku$.unload_method), ku$.xmltype_fmts
from sys.ku$_10_2_table_data_view ku$
where not bitand(ku$.base_obj.flags, 128) != 0 and
not(bitand(ku$.base_obj.flags, 16) = 16) and
ku$.base_obj.obj_num in(
select *
from table(DBMS_METADATA.fetch_objnums(100001)))
>
and it's the same for me: the more objects, the longer the expdp process takes. the operation finishes eventually.