Optimize icon storage to avoid a monolithic icons folder

[ksuriya]

In our current PIRService example setup, we’re provisioning and storing icon assets by simply dumping every icon file into a single icons/ directory. As the dataset grows (potentially millions of icons), this approach:

Degrades filesystem performance (slow directory listings, high lookup latency).
Consumes excessive memory when the directory index is cached or scanned.

Problem Statement:

Is there a recommended pattern or built‑in support in PIRService for organizing or indexing icon assets other than placing them all in one flat folder?

[karulont]

ConstructDatabase tool was meant as a quick and dirty way to get something going. In reality one would use a database. Instead of ContructDatabase that can load icons from a folder, you would have your own tool that reads them from your database.

[ksuriya]

Could you please provide more details on alternative approaches we could use instead of ConstructDatabase to load icons from a different directory ?

[karulont]

Have you read the source of ConstructDatabase? It is just combines some files together. And writes out a Apple_SwiftHomomorphicEncryption_Pir_V1_KeywordDatabase.

KeywordDatabase is just a list of keyword-value pairs.
For Live Caller ID Lookup, the value for identity is just a serialized protobuf of type CallIdentity: https://github.com/apple/pir-service-example/blob/main/Sources/ConstructDatabase/protobuf/CallIdentity.proto

So instead of using ConstructDatabase, you can write your own data converter that reads from whatever database software you use for storing the identities and converts them to the CallIdentity message.