Remove virtual thread counter from virtual thread name?

[He-Pin]

We currently have an ID in the virtual thread name, which will be increased every time. Does that need to be?
As we new a virtual thread for every message, I think we should just remove that counter to improve performance

[He-Pin]

@pjfanning wdyt about this, both have pron and cons

[pjfanning]

I'd prefer to make the thread names have some way to be different from each other and a number seems like a good way to do this.

[He-Pin]

I think we should remove this, because it call varhandle to increase the counter, and then the counter will be added to the thread name

See the hashcode of virtual thread, is delegate to thread id

[He-Pin]

I'd prefer to make the thread names have some way to be different from each other and a number seems like a good way to do this.

The current implementation doesn't make a 1:1 of actor to virtual thread, but eveytime the mailbox been scheduled, so we should drop this feature to improve performance or enable it behind a option

[mdedetrich]

In my view the best way to handle this would be to make a config option i.e. virtual-thread-disable-counter-id and have that default to true for 2.0.0

[He-Pin]

I agree ，I will tweak this this weekend

[He-Pin]

@mdedetrich do you think one mailbox one virtual thread will improve some performance ？I don't know how to do that without some locking, and compatible with the current asynchronous runtime.

So.the current is one invocation one virtual thread.

[mdedetrich]

@mdedetrich do you think one mailbox one virtual thread will improve some performance ？I don't know how to do that without some locking, and compatible with the current asynchronous runtime.

So.the current is one invocation one virtual thread.

Sorry I forgot about this.

Honestly in my view, with prod you shouldn't have any counter ids for virtual threads at all. You can have millions of these.

Just have a configuration setting for dev use/debugging

For performance just test it out, I am not too familiar with this part of the code

[pjfanning]

Could the default be -1 which disables this? Then, users can enable it be setting 0 or a positive value. Then users can optionally enable it for testing.

[He-Pin]

Yes, I think -1 is a better default, and we can even make it unnamed with better performance.