webhooktesting.ConvertToMutatingTestCases(webhooktesting.NewNonMutatingTestCases(serverURL), "test-webhooks")...)

	for _, tt := range testCases {
		// For now, skip failure cases or tests that explicitly skip benchmarking
		if !tt.ExpectAllow || tt.SkipBenchmark {
			continue
		}
		b.Run(tt.Name, func(b *testing.B) {
			wh, err := NewMutatingWebhook(nil)
			if err != nil {
				b.Errorf("failed to create mutating webhook: %v", err)

 * create the memory pressure required to cause soft references to be cleared.
 *
 * <p>This class only provides testing utilities. It is not designed for direct use in production or
 * for benchmarking.
 *
 * @author mike nonemacher
 * @author Martin Buchholz
 * @since 11.0
 */
@GwtIncompatible
@J2ktIncompatible
@J2ObjCIncompatible // gc
@ElementTypesAreNonnullByDefault

	}

	stopCh := make(chan struct{})
	defer close(stopCh)

	for _, tt := range webhooktesting.NewNonMutatingTestCases(serverURL) {
		// For now, skip failure cases or tests that explicitly skip benchmarking
		if !tt.ExpectAllow || tt.SkipBenchmark {
			continue
		}

		b.Run(tt.Name, func(b *testing.B) {
			wh, err := NewValidatingAdmissionWebhook(nil)
			if err != nil {

    // array slot is read and written exactly once. However, it can have very poor memory locality:
    // benchmarking shows it can take 7 times longer than the other two in some cases. The other two
    // do n swaps, minus a delta (0 or 2 for Reversal, gcd(d, n) for Successive), so that's about
    // twice as many reads and writes. But benchmarking shows that they usually perform better than

				stop := applyGCLoad(b)
				runOne(b)
				// Make sure to stop the timer before we wait! The load created above
				// is very heavy-weight and not easy to stop, so we could end up
				// confusing the benchmarking framework for small b.N.
				b.StopTimer()
				stop()
			})
		}
	}

	// Measure the cost of counting goroutines
	b.Run("small-nil", run(func() bool {
		GoroutineProfile(nil)
		return true

    // array slot is read and written exactly once. However, it can have very poor memory locality:
    // benchmarking shows it can take 7 times longer than the other two in some cases. The other two
    // do n swaps, minus a delta (0 or 2 for Reversal, gcd(d, n) for Successive), so that's about
    // twice as many reads and writes. But benchmarking shows that they usually perform better than

   *
   * <p><b>Performance note:</b> {@link ArrayList} and {@link java.util.ArrayDeque} consistently
   * outperform {@code LinkedList} except in certain rare and specific situations. Unless you have
   * spent a lot of time benchmarking your specific needs, use one of those instead.
   *
   * <p><b>Note:</b> this method is now unnecessary and should be treated as deprecated. Instead,

        int stride = 8;
        int minLength = Math.min(left.length, right.length);
        int strideLimit = minLength & ~(stride - 1);
        int i;

        /*
         * Compare 8 bytes at a time. Benchmarking on x86 shows a stride of 8 bytes is no slower
         * than 4 bytes even on 32-bit. On the other hand, it is substantially faster on 64-bit.
         */
        for (i = 0; i < strideLimit; i += stride) {

        int stride = 8;
        int minLength = Math.min(left.length, right.length);
        int strideLimit = minLength & ~(stride - 1);
        int i;

        /*
         * Compare 8 bytes at a time. Benchmarking on x86 shows a stride of 8 bytes is no slower
         * than 4 bytes even on 32-bit. On the other hand, it is substantially faster on 64-bit.
         */
        for (i = 0; i < strideLimit; i += stride) {

			}
		},
		func(q *core.ResourceRequirements, c fuzz.Continue) {
			randomQuantity := func() resource.Quantity {
				var q resource.Quantity
				c.Fuzz(&q)
				// precalc the string for benchmarking purposes
				_ = q.String()
				return q
			}
			q.Limits = make(core.ResourceList)
			q.Requests = make(core.ResourceList)
			cpuLimit := randomQuantity()
			q.Limits[core.ResourceCPU] = cpuLimit.DeepCopy()