Return to Question

Problem remains in 10.1

Earlier Kuba noted a major slowdown with code Simon Woods posted. Here is a simplified example.

First a color function using two different named gradient schemes:

fn = ColorData[If[# < 0.5, "CoffeeTones", "DeepSeaColors"]][#] &;

Now its use to colorize a random array:

Colorize[
 RandomInteger[99, {100, 100}],
 ColorFunction -> fn
] // AbsoluteTiming

This is conspicuously slow for such a simple operation. Interestingly this has nothing to do with Colorize or how it uses fn; it is inherent to fn itself:

fn /@ RandomReal[1, 100^2] // AbsoluteTiming // First

4.746

What's going on?

Bug introduced in V10.1 or earlier and persists through 11.2

Earlier Kuba noted a major slowdown with code Simon Woods posted. Here is a simplified example.

First a color function using two different named gradient schemes:

fn = ColorData[If[# < 0.5, "CoffeeTones", "DeepSeaColors"]][#] &;

Now its use to colorize a random array:

Colorize[
 RandomInteger[99, {100, 100}],
 ColorFunction -> fn
] // AbsoluteTiming

This is conspicuously slow for such a simple operation. Interestingly this has nothing to do with Colorize or how it uses fn; it is inherent to fn itself:

fn /@ RandomReal[1, 100^2] // AbsoluteTiming // First

4.746

What's going on?

Problem remains in 10.1

Earlier Kuba noted a major slowdown with code Simon Woods posted. Here is a simplified example.

First a color function using two different named gradient schemes:

fn = ColorData[If[# < 0.5, "CoffeeTones", "DeepSeaColors"]][#] &;

Now its use to colorize a random array:

Colorize[
 RandomInteger[99, {100, 100}],
 ColorFunction -> fn
] // AbsoluteTiming

This is conspicuously slow for such a simple operation. Interestingly this has nothing to do with Colorize or how it uses fn; it is inherent to fn itself:

fn /@ RandomReal[1, 100^2] // AbsoluteTiming // First

4.746

What's going on?

Problem remains in 10.1

Earlier Kuba noted a major slowdown with code Simon Woods posted. Here is a simplified example.

First a color function using two different named gradient schemes:

fn = ColorData[If[# < 0.5, "CoffeeTones", "DeepSeaColors"]][#] &;

Now its use to colorize a random array:

Colorize[
 RandomInteger[99, {100, 100}],
 ColorFunction -> fn
] // AbsoluteTiming

This is conspicuously slow for such a simple operation. Interestingly this has nothing to do with Colorize or how it uses fn; it is inherent to fn itself:

fn /@ RandomReal[1, 100^2] // AbsoluteTiming // First

4.746

What's going on?

Earlier Kuba noted a major slowdown with code Simon Woods posted. Here is a simplified example.

First a color function using two different named gradient schemes:

fn = ColorData[If[# < 0.5, "CoffeeTones", "DeepSeaColors"]][#] &;

Now its use to colorize a random array:

Colorize[
 RandomInteger[99, {100, 100}],
 ColorFunction -> fn
] // AbsoluteTiming

This is conspicuously slow for such a simple operation. Interestingly this has nothing to do with Colorize or how it uses fn; it is inherent to fn itself:

fn /@ RandomReal[1, 100^2] // AbsoluteTiming // First

4.746

What's going on?

Problem remains in 10.1

Earlier Kuba noted a major slowdown with code Simon Woods posted. Here is a simplified example.

First a color function using two different named gradient schemes:

fn = ColorData[If[# < 0.5, "CoffeeTones", "DeepSeaColors"]][#] &;

Now its use to colorize a random array:

Colorize[
 RandomInteger[99, {100, 100}],
 ColorFunction -> fn
] // AbsoluteTiming

This is conspicuously slow for such a simple operation. Interestingly this has nothing to do with Colorize or how it uses fn; it is inherent to fn itself:

fn /@ RandomReal[1, 100^2] // AbsoluteTiming // First

4.746

What's going on?