No, the length of time for which the shared pool latch is held when scanning for a free memory chunk is proportional to the length of the freelist unless a chunk of exactly the right size is found. By increasing the number of freelists, they have reduced the average length of the chains, and increased the probability of finding a chunk of exactly the right size immediately, thus they have reduced the risk of latch contention. There is no increased risk of latch contention from having more freelist headers, because the freelists are mutually exclusive based on the size of the chunks.

I noticed that the shared pool free list buckets in Oracle 8.1.6, as reported by your script shared_pool_free_lists.sql, is always 250 or above regardless of the size of the shared pool. But as you observed in your note with that script, the bucket numbers are different in earlier versions. What is the logic behind this? I was under the impression that large numbers of freelist will also cause shared pool latch contention. Am I wrong?