test is flawed.

measuring elapsed time is excessively misleading, you need to look at lots of other things... so -- lets see some more information:

first, I see different timing results (single user system, i'm the only CPU user -- big impact on test)

ops$tkyte@ORA920LAP> drop sequence s1;

Sequence dropped.

ops$tkyte@ORA920LAP> drop sequence s2;

Sequence dropped.

ops$tkyte@ORA920LAP>
ops$tkyte@ORA920LAP> create sequence s1 cache 20;

Sequence created.

ops$tkyte@ORA920LAP> create sequence s2 cache 1000000;

Sequence created.

ops$tkyte@ORA920LAP>
ops$tkyte@ORA920LAP> delete from run_stats;

0 rows deleted.

ops$tkyte@ORA920LAP> commit;

Commit complete.

ops$tkyte@ORA920LAP>
ops$tkyte@ORA920LAP> declare
  2      l_start number;
  3      l_run1  number;
  4      l_run2  number;
  5      l_x     number;
  6  begin
  7      insert into run_stats
  8      select 'before', stats.* from stats;
  9
 10      l_start := dbms_utility.get_time;
 11      for i in 1 .. 100000
 12      loop
 13          select s1.nextval into l_x from dual;
 14      end loop;
 15      l_run1 := (dbms_utility.get_time-l_start);
 16      dbms_output.put_line( l_run1 || ' hsecs' );
 17
 18      insert into run_stats
 19      select 'after 1', stats.* from stats;
 20      l_start := dbms_utility.get_time;
 21      for i in 1 .. 100000
 22      loop
 23          select s2.nextval into l_x from dual;
 24      end loop;
 25      l_run2 := (dbms_utility.get_time-l_start);
 26      dbms_output.put_line( l_run2 || ' hsecs' );
 27      dbms_output.put_line
 28      ( 'run 1 ran in ' || round(l_run1/l_run2*100,2) ||
 29        '% of the time' );
 30
 31      insert into run_stats
 32      select 'after 2', stats.* from stats;
 33  end;
 34  /
1323 hsecs
898 hsecs
run 1 ran in 147.33% of the time

PL/SQL procedure successfully completed.


<b>Now, looking at system statistics and latching:</b>


ops$tkyte@ORA920LAP> select a.name, b.value-a.value run1,
  2         c.value-b.value run2,
  3         ( (c.value-b.value)-(b.value-a.value)) diff
  4    from run_stats a, run_stats b, run_stats c
  5   where a.name = b.name
  6     and b.name = c.name
  7     and a.runid = 'before'
  8     and b.runid = 'after 1'
  9     and c.runid = 'after 2'
 10     and (c.value-a.value) > 0
 11     and (c.value-b.value) <> (b.value-a.value)
 12   order by abs( (c.value-b.value)-(b.value-a.value))
 13  /


STAT...session logical reads       320207     300046     -20161
LATCH.shared pool                  225174     200165     -25009
LATCH.row cache objects             30048         46     -30002
LATCH.enqueue hash chains           30037         23     -30014
LATCH.library cache pin            440136     400120     -40016
LATCH.library cache                560326     500306     -60020
STAT...session pga memory max       65536          0     -65536
LATCH.cache buffers chains         666008     600232     -65776
STAT...recursive calls             170039     100045     -69994
STAT...redo size                  4367648      28328   -4339320

78 rows selected.

<b>the second one generates lots less redo (alot), does less work, latches a whole lot less (remember a latch is a lock, locks are serialization devices, serialization devices inhibit scalability....)</b>


So, in a multi-user environment or large data load -- having higher cache values will be more scalable, more performant.


Hopefully a system would not require a user to type in such a number?  I mean, where would the number come from in the first place?  these surrogate keys are used to tie the data together but are rarely manually entered
 

sure, as long as you don't mind "losing" 1,000,000 sequences in the event of a shutdown abort/crash.

don't worry about running out of sequences.  Even if you shutdown abort once a second, it would take:

ops$tkyte@ORA920> select (rpad( '9',27,'9' ) / 1000000)/60/60/24/366 from dual;

(RPAD('9',27,'9')/1000000)/60/60/24/366
---------------------------------------
                             3.1623E+13

that many years to run out.