Feature: CreateId that accepts generator ID as argument about idgen

[RobThree]

The reason being blocking a thread takes away a thread that could have processed another request.

For long-running tasks or being memory-, cache- or I/O bound. But IdGen is CPU bound and not long running and the locks aren't for any long running tasks. If you have changed this in your local copy, could you benchmark it compared to this version and share your results?

[RobThree]

Why not use the specific generator to generate an Id? Just create an instance of each generator (I'd keep them around, maybe in an array or dictionary or...) and call CreateId() on the generator that you want?

[AachoLoya]

I did think by doing that, but our logic is a bit complex so we'd have to maintain an array of 16+ generators. Not unreasonable, but thought if we could just pass generator Id in createId, it'll be a lot cleaner code.

[AachoLoya]

Another feature would be to replace the lock with SemaphoreSlim(1,1) - which allows WaitAsync, and make the method CreateId async, so that it can be used in asp.net without affecting performance.

[RobThree]

I did think by doing that, but our logic is a bit complex so we'd have to maintain an array of 16+ generators. Not unreasonable, but thought if we could just pass generator Id in createId, it'll be a lot cleaner code.

It may be cleaner code in your case but I think it clouds the code for the general usecase. You're using IdGen's generator ID "creatively" to 'bend' it to encode some other info into the Id; I don't think that's the case we should design for.

Another feature would be to replace the lock with SemaphoreSlim(1,1) - which allows WaitAsync, and make the method CreateId async, so that it can be used in asp.net without affecting performance.

There's nothing async about the method; and making it async doesn't magically improve performance somehow. The method is fast _{(there's probably some room for improvement)} and I don't see how making it async would improve matters. It's like asking for a Guid.NewGuidAsync().

[AachoLoya]

It may be cleaner code in your case but I think it clouds the code for the general usecase. You're using IdGen's generator ID "creatively" to 'bend' it to encode some other info into the Id; I don't think that's the case we should design for.

If you look at other derivates of Snowflake , e.g. Instagram, discord, they all took the format but adopted it, mainly the middle part (generator Id) to their own usage. It's upto you if the change is worth it or not. I decided to just made a local copy of this project and modified the code and locking to fit our usage.

There's nothing async about the method; and making it async doesn't magically improve performance somehow. The method is fast (there's probably some room for improvement) and I don't see how making it async would improve matters. It's like asking for a Guid.NewGuidAsync().

In asp.net any thread blocking call is strongly discouraged, which is exactly what 'lock' does. The reason being blocking a thread takes away a thread that could have processed another request. That's the reason why SemaphoreSlim was introduced, so you can await on the semaphore by calling WaitAsync, without actually blocking a thread.

These are just my suggestions, still the project was really helpful for us. Thanks!