FakeValuesService sharing across Faker instances — by design or possible enhancement?

[mferretti]

Hi,
I use DataFaker heavily in SeedStream; here I run multiple parallel threads to generate test data and I noticed a significant CPU overhead and traced it back to Faker instantiation and per-instance YAML loading but fixed most of it with a thread-local Faker:

private static final ThreadLocal<Map<Locale, Faker>> CACHE = ThreadLocal.withInitial(HashMap::new);
public static Faker getOrCreate(Locale locale, Random random) {
    return CACHE.get().computeIfAbsent(locale, loc -> new Faker(loc, random))
}   

Profiling again after this change, I can see each Faker instance still builds its own FakeValuesService with its own fakeValuesInterfaceMap. With 8 threads all using the same Locale, the same YAML gets loaded 8 times into 8 separate maps. Same goes with expression templates: compiled and cached inside each FakeValuesService independently via EXPRESSION_2_SPLITTED and expression2generex.
Digging some more I noticed that BaseFaker has a constructor:
public BaseFaker(FakeValuesService fakeValuesService, FakerContext context)

This makes me think that sharing a single FakeValuesService across multiple Faker instances is at least architecturally possible.
In the average scenario I am working on, all threads use the same locale and only differ in their Random: a shared, read-only FakeValuesService with per-instance FakerContext could work.

At this point I have a few questions

1. Is the current design — one FakeValuesService per Faker — intentional for thread-safety or isolation reasons I might be missing?
2. Are there concurrency issues in sharing a FakeValuesService across Faker instances with different Random instances?
3. Would a factory method like Faker.withSharedService(FakeValuesService shared, Locale locale, Random random) be something you would consider? It would let callers manage a shared, pre-warmed service and pass it in, with each Faker only owning its FakerContext.
4. Alternatively, would a FakeValuesServiceFactory.getShared(Locale) singleton pattern fit the library's design philosophy?

Happy to contribute if the approach sounds reasonable and there are no blockers I'm missing.
Thanks for any insight.

[asolntsev]

@mferretti I don't know about the initial design choices, but I believe performance was a priority. So your finding might help us to improve the performance.

Can I ask first: why do you need to run parallel threads with different Randoms? What's the point?

[bodiam]

@mferretti

Is the current design — one FakeValuesService per Faker — intentional for thread-safety or isolation reasons I might be missing?

I'm not sure. It's not a "it must be isolated or else...", I believe it's just an implementation choice to do it like because this worked.

Are there concurrency issues in sharing a FakeValuesService across Faker instances with different Random instances?

Great question also. I can't answer that, but there's no reason why we would be against it, I think. If you have an implementation in mind which will speed up the generation in a multithreaded environment, and we don't change our APIs too much (ideally no change to very public APIs, but we're thinking of releasing a 3.0 anyway, so a few breaking API changes could be allowed), then I see no issue

Would a factory method like Faker.withSharedService(FakeValuesService shared, Locale locale, Random random) be something you would consider? It would let callers manage a shared, pre-warmed service and pass it in, with each Faker only owning its FakerContext.

I see no problem with, no objection from my end

Alternatively, would a FakeValuesServiceFactory.getShared(Locale) singleton pattern fit the library's design philosophy?

I think the main driver here is: what works for you. If you have an implementation in mind which helps you, and doesn't affect any other consumers, I don't think we have to discuss much: we'd be more than happy to accept the PR. If public APIs change, it's a bit more involved, but if we can keep it limited, we can put it in 3.0.

We have quite a bit of tests in place for multithreaded code, plus we have a benchmark here: https://github.com/datafaker-net/datafaker-benchmark. If all tests pass, and the benchmark can show a positive effect for your usecase, more than happy to accept contributions.

[mferretti]

ok, I opened the PR and am waiting for your review.

[mferretti]

@asolntsev , sorry ... I thought I replied but I did it only in my head :(.
SeedStream is a test data generator where reproducibility is a first-class feature: given a fixed seed and configuration, the same output must be produced every time, regardless of how many threads are used. Now, in order to produce lots of data the library permits you to fork the data production in different threads, depending on the configuration you pass.
The way it works: a top-level job seed is split into per-thread seeds (e.g. workerSeed = jobSeed + threadIndex). Each thread then operates with its own new Random(workerSeed), making every thread's sequence fully deterministic and independent of scheduling.
The change in the PR enables fine tuning of the library by not touching this strategy at all: the Randoms stay per-thread, the only thing being shared is the read-only FakeValuesService, which currently gets loaded n times when n threads use the same locale, and waste memory and speed. If interested, here's the full explanation https://github.com/mferretti/SeedStream/blob/main/docs/DESIGN.md#seeding--reproducibility