I wonder if there is some corruption somewhere, like a table that lost its indexes, or a lot of orphans, or a hierarchy that is particularly bonkers. Maybe some optimization could be done at the db level, logging the queries to determine where the slowdown is (you can use ReadMemberPropertiesNoCache to ensure you're hitting the database every time).
In any case, if the api really is that slow, you can speed things up by doing the reading part via SQL directly on the MemberProperty table (you just have to figure out the PropertyID for Text5, but that should be easy enough), and then use the api only for the specific members that need changing.
I timed around every call and it is the ones I shared. We pull the ids so we know those. Hitting the backend just to see what has changed may be the way we have to go. I do not want to update that way as there is supposed to be history, logging, etc taking place and SOX would likely not like the direct updates. WIll see what this buys us. In any event, this still does not address the 2 second call per member which is terrible.
I agree those 2 seconds don't seem normal to me. You should probably take it up with support - to speed up the experience, you might want to build the smallest Business Rule that can trigger the 2secs wait, so they can take it and run it on reference environments to figure if it's a bug or an environmental issue - in which case, they will want to look at your app. Good luck!
