Compiler crash with large numbers and some y-tick-step values

[linuxrider]

The compilers crashes on certain values for y-tick-step e.g. 1e12 and 1e6. In between for 1e10 it works and the expected message is displayed.
Is this related to cetz or the compiler?

#import "@preview/cetz:0.1.2": canvas, plot, draw
#set page(width: auto, height: auto)

// Ok
// assertion failed: Number of major ticks exceeds limit.
// #canvas(
//   {
//     import draw: *
//     plot.plot(size: (8, 6),
//     y-tick-step: 1e10, // this seems to be the parameter to crash  the compiler
//       { 
//         plot.add(style: (stroke: (paint:blue)),
//           domain: (0, 1), samples: 300, rho => 1e15*rho
//         )
//       }
//     )
//   }
// )

// compiler crash
// #canvas(
//   {
//     import draw: *
//     plot.plot(size: (8, 6),
//     y-tick-step: 1e12, // this seems to be the parameter to crash  the compiler
//       { 
//         plot.add(style: (stroke: (paint:blue)),
//           domain: (0, 1), samples: 300, rho => 1e15*rho
//         )
//       }
//     )
//   }
// )

// compiler crash
#canvas(
  {
    import draw: *
    plot.plot(size: (8, 6),
    y-tick-step: 1e6, // this seems to be the parameter to crash  the compiler
      { 
        plot.add(style: (stroke: (paint:blue)),
          domain: (0, 1), samples: 300, rho => 1e15*rho
        )
      }
    )
  }
)

[fenjalien]

I would say the crash is coming from the use of 1e15 * rho in your function which causes at least 34GBs of memory allocation which is just crazy. Not entirely sure what the purpose of tic-limit is @johannes-wolf but for some reason it causes an assertion to fail before the giant memory allocation can work its magic.

[johannes-wolf]

I would say the crash is coming from the use of 1e15 * rho in your function which causes at least 34GBs of memory allocation which is just crazy. Not entirely sure what the purpose of tic-limit is @johannes-wolf but for some reason it causes an assertion to fail before the giant memory allocation can work its magic.

The purpose is to limit the number of ticks drawn, although the check comes too late in this case.
With #405 I changed the check to be done before creating the (possibly) huge tick array.

Then OOM crash is due to allocation of a huge array because of the low tick-step value and the high plot values leading to a lot of ticks.

[linuxrider]

Does this also explain that the compiler crash does not occur in middle of the tested y-tick-step range e.g. for 1e10?

[johannes-wolf]

Yes, because of the fewer ticks, fewer memory gets allocated.

[linuxrider]

I don't understand: y-tick-step = 1e12 generates less ticks than y-tick-step = 1e10. And still the compiler crashes for y-tick-step = 1e12 but not for y-tick-step = 1e10.

y-tick-step = 1e12 = crash
y-tick-step = 1e10 = no crash
y-tick-step = 1e6 = crash

[johannes-wolf]

I did not test why this happens, but it should be fixed on 0.2.0 now.