JDBC backend: getCatalogTree() re-escapes the backend id and allocates a TreeName on every call, including per table in a clear's leftover scan

[vharseko]

Lands with #893, which is where getCatalogTree() and escapedBackendId() are: they are not on master yet.

Problem

The tree catalog of a backend is named after its backend id, and the id is escaped into that name the way PersistentCompressedSchema escapes it into its own prefix. Both the escaping and the TreeName are done again on every call:

TreeName getCatalogTree() {
    return new TreeName(CATALOG_BASE_DN, escapedBackendId());   // two String.replace passes, then an allocation
}

The backend id is fixed for the life of the storage, and so, therefore, are the escaped id, the catalog TreeName and the base DN of this backend's own compressed schema pair.

Where it is paid

• enrolInCatalog(), unenrolFromCatalog() and isEnrolledTree() each call it, so a stock suffix pays it about 25 times on every read-write open, and once more per tree of every later openTree that enrols;
• catalogTables() and removeStorageFiles() call it per clear;
• isOwnTree() calls both getCatalogTree() and ownCompressedSchemaBaseDN() — which escapes the id again — for every table the leftover scan reports, so a clear on a shared database (JDBC backends sharing a database URL share one pair of compressed-schema tables #873) pays four escapes and two allocations per standing table.

What the fix looks like

final fields initialised in the constructor from config.getBackendId(), and the accessors reading them. Nothing about the id changes while a storage lives, and JDBCStorage already memoizes the far more expensive per-tree table name in tree2table for the same reason.

Severity

Small and never on a hot path — a clear and a backend open are cold. Filed because it is the sort of thing that only gets fixed when it is written down, and because two separate passes over this code raised it.