Performance Bottleneck in nodejs-polars When Creating Multiple Expr Objects

[chenstarx]

Have you tried latest version of polars?

• [yes]

What version of polars are you using?

0.0.15

What operating system are you using polars on?

MacOS 14.4.1 (M3 Pro)

What node version are you using

v20.12.1

Describe your bug.

I have encountered a significant performance issue when using the nodejs-polars library. Specifically, the time required to create multiple Expr objects is considerably higher compared to the Python version of polars.

What are the steps to reproduce the behavior?

To illustrate the issue, I conducted a performance test by generating one million Expr objects in both nodejs-polars and Python polars. The following code snippets demonstrate the test setup:

Python Code

import polars as pl
import time

start_time = time.time()

for _ in range(1000000):
    _ = pl.col("A") > pl.lit(1)

end_time = time.time()
print(f"Time taken in Python: {end_time - start_time} seconds")

Node.js Code

const pl = require('nodejs-polars');
console.time('Expr Creation');

for (let i = 0; i < 1000000; i++) {
  const expr = pl.col("A").gt(pl.lit(1));
}

console.timeEnd('Expr Creation');

What is the actual behavior?

Python polars: Approximately 7 seconds to create 1,000,000 Expr objects.
Node.js polars: Approximately 1,000 seconds to create the same number of Expr objects.

• Each iteration of the for loop took approximately 1ms

Impact

This performance discrepancy presents a significant bottleneck when performing operations that require frequent creation of Expr objects in nodejs-polars. It substantially limits the library's usability for large-scale data processing tasks in a Node.js environment.

What is the expected behavior?

The performance of creating Expr objects in nodejs-polars should be closer to, or ideally match, the performance in the Python version of polars.

Possible Reason

The issue might be caused by _Expr that will create an new Expr object when executed. Each execution will take about 0.5ms in my laptop, consuming considerable time if executed million times. Moreover, In my test dataset, the actual computing time for millions rows of data is very short, most of the time was wasted in creating the Expr objects.

There might be two ways to solve this problem:

1. Rewriting _Expr with class, and return this in each expression method, avoiding time-consuming operations of creating a complex new object in javascript.
2. Turning the Expr into mutable object, updating its attributes rather than creating an new object in each expression.

Thanks for reading the issue, I hope my suggestion would be helpful for the nodejs-polars library.

[maizhichao]

I encountered the same issue.

[Bidek56]

It's partly a node issue, have you tried bun or deno? I get much better performance using those 2 vs. node

[maizhichao]

It's partly a node issue, have you tried bun or deno? I get much better performance using those 2 vs. node

My project highly depends on Node.js, it's hard to migrate to Bun or Deno...

[Bidek56]

Anything other operation using node takes much longer than using Bun
For example I just tried: [...Array(1_000_000)].forEach((_, i) => pl.Series("abs", [1, 2, 3]));
It takes many times longer in node than in Bun
Why do you think re-writing just _Expr will solve your performance issue?

[Bidek56]

For me Bun is 20% faster than Python when running: [...Array(1_000_000)].forEach((_, i) => pl.Series("abs", [1, 2, 3]));

[universalmind303]

@maizhichao unfortunately, this is a known issue with nodejs. Their FFI implementation is incredibly slow compared to python or other js engines (deno, bun). The main bottleneck is sending values over n-api, which refactoring Expr will not fix.

[bitofsky]

We also encountered this issue while attempting to adopt Polars Nodejs in our project.

Even considering the overhead caused by Nodejs FFI, taking 1ms just to create a simple expression (Expr) — not even executing an operation — seems too slow.

I am not a data analytics specialist, but my understanding is that Expr is an object representing a Polars expression. From the first Expr to the chained ones, expressions are created immutably, and I believe that Expr objects created with the same steps and arguments will always be identical.

If that's the case, wouldn't it be more efficient to cache the entire process of chaining Exprs and convert them to native only at the final usage point, rather than always going through native bindings for each step?

Of course, performance can be somewhat improved by manually moving the Expr creation to upper scopes for reuse, but this becomes a very tedious and exhausting task.

It would be great if there’s a way to improve performance without making large code changes.

We've come up with a few possible immediate solutions, and we tested one of the simplest ideas, which significantly improved performance in our case while preserving the correctness of the result.

The idea is simple: we wrap the Expr creation code with Tagged Template literals, cache them, and when there’s no cache, generate the Expr using new Function().

We first identified code where Expr creation is frequent and affects performance, and wrapped it using plx and pll utilities:

import { plx } from './utils';

console.time('Expr Creation');

for (let i = 0; i < 1000000; i++) {
  const expr = plx`pl.col("A").gt(pl.lit(1))`;
}

console.timeEnd('Expr Creation');

// Output: Expr Creation: 161.883ms

Let’s look at a few examples from our codebase. The following shows how you can use plx and pll with tagged templates to cache expressions:

df
  .filter(pl.col('dd').eq(pl.lit('A')))
  .withColumns(
    pl.col('a_x')
      .sub(pl.col('v_x'))
      .pow(2)
      .add(
        pl.col('a_y')
          .sub(pl.col('v_y'))
          .pow(2)
      )
      .add(
        pl.col('a_z')
          .sub(pl.col('v_z'))
          .pow(2)
      ).pow(0.5).alias('dd'),
    pl.col('vid').alias('a'),
  )
  .select('a','dd')

import { plx, pll } from './utils';

df
  .filter(plx`pl.col('dd').eq(pl.lit('A'))`)
  .withColumns(
    ...pll`
    pl.col('a_x')
      .sub(pl.col('v_x'))
      .pow(2)
      .add(
        pl.col('a_y')
          .sub(pl.col('v_y'))
          .pow(2)
      )
      .add(
        pl.col('a_z')
          .sub(pl.col('v_z'))
          .pow(2)
      ).pow(0.5).alias('dd'),
    pl.col('vid').alias('a'),
    `
  )
  .select('a','dd')

The utilities plx and pll used above are implemented as follows. They haven't been extensively tested, but they are working well in our current use cases:

// utils.ts
import * as pl from 'nodejs-polars';

type plType = pl.DataType | pl.Expr | pl.Series | string;

const plxCache = new Map<string, plType>();
const pllCache = new Map<string, plType[]>();

function buildCode(strings: TemplateStringsArray): { code: string; params: string[] } {
  let code = '';
  const params: string[] = [];
  for (let i = 0; i < strings.length - 1; i++) {
    code += strings[i] + `__v${i}`;
    params.push(`__v${i}`);
  }
  code += strings[strings.length - 1];
  return { code: code.trim(), params };
}

export function plx<T extends plType = pl.Expr>(strings: TemplateStringsArray, ...exprs: any[]): T {
  const { code, params } = buildCode(strings);
  const cacheKey = code + JSON.stringify(exprs);
  let r = plxCache.get(cacheKey);

  if (r) return r as T;

  try {
    r = new Function('pl', ...params, `return (${code});`)(pl, ...exprs);
  } catch (e) {
    console.error(`Error in plx: ${e}. Code: ${code}, Params: ${JSON.stringify(exprs)}`);
    throw e;
  }

  plxCache.set(cacheKey, r!);

  return r as T;
}

export function pll<T extends plType = pl.Expr>(strings: TemplateStringsArray, ...exprs: any[]): T[] {
  const { code, params } = buildCode(strings);
  const cacheKey = code + JSON.stringify(exprs);
  let r = pllCache.get(cacheKey);

  if (r) return r as T[];

  try {
    r = new Function('pl', ...params, `return [${code}];`)(pl, ...exprs) as T[];
  } catch (e) {
    console.error(`Error in pll: ${e}. Code: ${code}, Params: ${JSON.stringify(exprs)}`);
    throw e;
  }

  pllCache.set(cacheKey, r);

  return r as T[];
}

The Expr created with the same template string and the same arguments always returns the same object. For dynamic generation of expressions, ${expression} can be passed as a parameter.

However, if the expression varies frequently, it may cause memory leaks. So it’s better to manage cache with LRU in such cases or avoid using this utility entirely.

import { plx, pll } from './utils';

df
    .unique({ subset: ['a', 'b'] })
    .select(
      'a',
      'b',
      ...pll`
      pl.col('g').alias('g_s'),
      pl.col('d').alias('d_b'),
      pl.col('r')
        .round(1)
        .cast(pl.Utf8)
        .alias('r_s'),
      `,
      ...pll`${['A', 'B', 'C', 'D', 'E']} // When dynamically generating expressions
        .map((c) =>
          pl.col(c)
            .round(1)
            .cast(pl.Utf8)
            .alias(\`\${c}_s\`)`
        )
      `,
    )

This approach significantly improved our performance, but it is clear that this kind of dirty caching is not an ideal solution.

It would be very helpful if Polars Nodejs could fundamentally improve the performance of Expr creation.