Is there any change if you enable the keyboxd to store the keys? Put

use-keyboxd

into ~/.gnupg/common.conf.

Let me try, this problem sometimes happens, so it may takes some time to come to a conclusion.
But what I know is that after experiencing slow loading, it will not appear again when it is opened again later.

This could be caused by the periodic automatic update of the Web of Trust information. See --auto-check-trustdb in man gpg.

Put no-auto-check-trustdb in your gpg.conf to disable this (and create a cronjob or scheduled task which runs gpg --check-trustdb when it doesn't bother you, e.g. in the night).

Which reminds me that we should add a cronjob feature to dirmngr (which already does some background tasks) so that we can easiliy make use of --no-auto-check-trustdb on Windows.

Yes, I infer that the problem lies in the network-related modules. Because this waiting time is too long, it is probably not a problem of calculation and disk.

Put

debug network,dns,ipc
log-file something

into dirmngr.conf to see what's going on.

debug network,dns,ipc
log-file C:\Users\Administrator\dirmgr.log

I wrote this in my dirmngr.conf. But i haven't found this .log file.

Did you restart dirmngr? ("gpgconf --kill dirmngr" so it will be started on demand).

Do you have write permissions to the directory; that is: Do you run gpg under the Administrator account?

###+++--- GPGConf ---+++###
allow-version-check
keyserver hkps://hkps.pool.sks-keyservers.net:80
###+++--- GPGConf ---+++### 2021/5/8 14:18:58
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.

debug network,dns,ipc
log-file P:\dirmgr.log

This is what my configuration file looks like now. I executed the restart command to confirm that the current user has write access to the directory. Is my path format wrong?

keyserver hkps://hkps.pool.sks-keyservers.net:80 is problematic.

The combination of hkps and :80 is strange and may not work because HTTP connections on port 80 are usually not TLS secured. But more problematic is that hkps.pool.sks-keyservers.net is dead, i.e. it does not resolve anymore to any servers. You need to use another keyserver. Try hkp://pgp.surf.nl or hkps://keyserver.ubuntu.com instead, but note that for me the former is very slow (a simple --recv-keys of a single key takes 30+ seconds) and, again for me, the latter is even slower or doesn't answer at all.

I have recently been busy with the new features and mechanisms of the GpgFrontend project.

Now I located the API interface of GpgME corresponding to this problem.

gpgme_error_t gpgme_op_keylist_next(gpgme_ctx_t ctx, gpgme_key_t *r_key)

When this function is executed each round of the loop, it always takes a long time to return.

After several days of observation, after modifying the configuration file options , the problem has indeed been greatly alleviated.

keyserver hkps://keyserver.ubuntu.com