I would say 600 MB is on the high end. On my laptop the memory usage is:
bdservicehost.exe (there are 5 services): 400 + 14 + 13 + 6 + 8 for a total of ~440MB
bduserhost.exe (multiple instances): ~10MB
bdagent.exe: 18MB
bdntwrk.exe: 3MB
bdredline.exe: 2MB
obkagent.exe: 4MB (if running)
bdvpnservice: ~5MB
So with all running, it's around 480MB. The range I am usually see is in 400-600 MB.
So on your machine 600 MB I would say is on the high limit, but that depends also on the particularity of what runs and happens on it - but yes, it is on the standard memory usage.
The reason for why the memory consumption is on that value is simply the product does a ton of things. Setting an option to OFF, for example, disables, say realtime functionalities, but that does not mean the module is unloaded, it is just running with less capabilities, registering less I/O with the operating system and so on.
For the multiple bdservicehost.exe executables you are seeing, the reason is simpler: once upon a time there was a single service (vsserv.exe - what you see now bdservicehost.exe that occupies the most of the memory) where everything was cramped. I was one of the proponents of "let's not keep everything in one process, and keep only the proxies there and spawn another processes as necessary". This is, for example, why the entire vulnerability scanning, which once was in the service, was moved in the vulnerability.scan.exe which executes only when the scan needs to be done, reports the results, then stops. There are now separate services for core/defense functionalities (bdservicehost.exe Virus Shield); vulnerability, wifi, networking (bdservicehost.exe BDAuxSrv); application service (bdservicehost.exe BDAppSrv); Safepay service (bdservicehost.exe BDSafepaySrv), and the protected service which ensures integrity (bdservicehost.exe BDProtSrv). All these are to maintain separate and self-functioning (to a degree) various components, and avoid that a bug or crash in one of them to drag everything down.
The same for bduserhost.exe various instances, which, in addition of avoiding cramping everything into the user agent (bdagent.exe), are also needed to execute in the user's context: for example, when wifi networks changed, audio/video protection is enabled etc. (a wifi network or Zoom call occurs in the context of an user but not for another user, for example).
The reality, as I see it, comes down to three things: one is to avoid troubles by putting all the eggs in one basket (which I think we succeed, although this complicated our life tremendously - but it's not our life which needs to be nice, but the user life
), the second is the product offers so much functionality (but this comes with a cost), and third, which we are currently ongoing do, is to keep things as slim as possible by avoiding doing more than necessary while keeping things running correctly. The latter is an ongoing thing which we are doing (in fact, I am working on a part of the product optimization right now).
I hope I managed to clarify a little bit the why.
