prisma: Other packages make Prisma load very slow

Bug description

Tested this with a file where I’m just importing the client:

const { PrismaClient } = require('@prisma/client')

With 2.23 this loads in under a second, whereas on 2.24 and beyond it takes roughly 12-13 seconds each time.

This is a bit of a major issue for us when it comes to our testing, and just generally slows down the dev flow. Is this a known issue, and is there any way to reduce the load time?

How to reproduce

Can add our schema if needed, just a bit large so didn’t add it right away.

Expected behavior

Load as fast as before.

Environment & setup

  • OS: Mac OS
  • Database: PostgreSQL
  • Node.js version: 15.14.0

Prisma Version

2.28.0

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 19 (10 by maintainers)

Most upvoted comments

We ran into this issue too, and it seems to be caused by the bug reported in #7808 (and fixed by #9295 in 3.1.0). Basically when trying to import Prisma client, a call is made that looks like the following:

const dirname = findSync(process.cwd(), [
  '"node_modules/.prisma/client/db"',
  '".prisma/client/db"',
], ['d'], ['d'], 1)[0] || __dirname

Notice the double-quotes inside single quotes. These paths don’t exist, and so it seems Prisma resorts to searching every module inside node_modules, which is as reported very slow.

Testing with a simple time node -e "require('@prisma/client')" on my machine takes 1.3 seconds, but manually fixing the two lines in the generated files to remove the extra quotes causes the same command to take 0.6 seconds. If it’s helpful for anyone, we’ve incorporated some sed commands into our CI/CD to automatically rewrite these double-quoted lines as a temporary speedup while we work on upgrading to a more recent Prisma version:

sed -i "s|'\\\"node_modules/.prisma/client\\\"'|'node_modules/.prisma/client'|g" node_modules/.prisma/client/index.js
sed -i "s|'\\\".prisma/client\\\"'|'.prisma/client'|g" node_modules/.prisma/client/index.js

I can confirm this is no longer an issue in 3.3

I did a clean start with the above minimal example and I can finally reproduce this!!

Even generate is quite slow:

image

Marking as regression. This will need more investigation.

I’m using Prisma inside of an Electron app. This is perhaps a not supported/intended use of Prisma. But FYI, when run by Electron, process.cwd() returns “/”. So the findSync call scans from the root directory which takes a long time (~60s).

I’m working around this by running a build script that replaces process.cwd() with require('electron').app.getAppPath() in the generated client code:

const dirname = findSync(require('electron').app.getAppPath(), [
    "src/generated/client",
    "generated/client",
], ['d'], ['d'], 1)[0] || __dirname

This cuts down the time it takes to instantiate the Prisma client to ~10ms.

Ok it appears to be a package issue - if I install just the prisma packages it works fine, but something in our package list is causing problems.

Schema:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model Address {
  createdAt DateTime @default(now())
  id        String   @id @default(cuid())
  updatedAt DateTime @updatedAt
}

Dependencies:

{
  "dependencies": {
    "@graphql-tools/load-files": "^6.2.5",
    "@graphql-tools/merge": "^6.2.6",
    "@prisma/client": "^2.28.0",
    "@rabble-inc/payments": "^3.0.0",
    "@slack/webhook": "^5.0.3",
    "apollo-server-express": "^2.16.1",
    "aws-sdk": "^2.673.0",
    "axios": "^0.19.2",
    "bcryptjs": "^2.4.3",
    "check-types": "^11.1.2",
    "cookie-parser": "^1.4.5",
    "cryptr": "^6.0.2",
    "date-fns": "^2.13.0",
    "date-fns-tz": "^1.1.1",
    "dotenv": "^8.2.0",
    "express": "^4.17.1",
    "geo-tz": "^6.0.1",
    "geolib": "^3.3.1",
    "graphql": "14.6.0",
    "graphql-tools": "^5.0.0",
    "handlebars": "^4.7.6",
    "jsonwebtoken": "^8.5.1",
    "lodash": "^4.17.15",
    "mjml": "^4.6.3",
    "nanoid": "^3.1.20",
    "node-geocoder": "^3.27.0",
    "node-schedule": "^1.3.2",
    "postmark": "^2.5.3"
  },
  "devDependencies": {
    "@rabble-inc/local-ip": "^1.0.0",
    "cross-env": "^7.0.2",
    "dotenv-cli": "^3.2.0",
    "eslint": "^7.0.0",
    "eslint-config-prettier": "^6.11.0",
    "eslint-plugin-jest": "^23.10.0",
    "eslint-plugin-node": "^11.1.0",
    "eslint-plugin-prettier": "^3.1.3",
    "eslint-plugin-sort-destructure-keys": "^1.3.4",
    "faker": "^4.1.0",
    "husky": "^4.2.5",
    "jest": "^26.0.1",
    "mockdate": "^2.0.5",
    "nodemon": "^2.0.3",
    "pg": "^8.5.1",
    "prettier": "^2.0.5",
    "prisma": "^2.28.0",
    "random-location": "^1.1.3",
    "randomcolor": "^0.5.4"
  }
}

And then testing it by just running this file:

const { PrismaClient } = require('@prisma/client')

console.log('loaded')

If both 2.23 and 2.29 are “similarly slow” for you @boan-anbo then you do not have the same problem as the original poster in this issue - they are explicitly reporting an increase in the loading time. Please open a new issue instead for your problem.

I think it’s the same issue given https://github.com/prisma/prisma/issues/8484#issuecomment-895897833, and that this issue is perhaps mislabeled. It’s not (just) the version change but conflicts, as @jwld already pointed out, with other packages that’s causing the slow loading time. I just tried Prisma with

  "devDependencies": {
    "@types/jest": "^27.0.0",
    "jest": "^27.0.6",
    "ts-jest": "^27.0.4",
    "typescript": "^4.3.5"
  },
  "dependencies": {
    "@prisma/client": "^2.29.0"
  }

The instantiation is instant. So I think the two issues are related, and it’s uncertain whether version change is clearly isolated as the sole cause for the problem. But if you insist I’ll open another issue.