5E Product Walkthrough Playlist
Page 4 of 4 First ... 234
  1. #31
    With the fixes put in place in 4.1.9 (reduces it to 3-4 seconds) and the above changes it is now less than 1.5 seconds and sometimes as low as 0.7 seconds.

    In fact it is a repeating pattern (which concerns me somewhat). First save is 1.2s, next is 0.7s, next is 1.2s, next is 0.7s (repeating).



    Jason
    Last edited by jharp; September 29th, 2021 at 04:32.

  2. #32
    I don't know if that's running for every string being saved or some small subset, but if it's all and it's iterating over every character in strings so that it can do character replacement/appending/encoding or whatever it's doing there, that would definitely explain why save is so slow.

  3. #33
    The four functions iterate over a large subset (or complete set) of characters in the save.

  4. #34
    Kind of curious how string.replace or RegEx.replace would perform, too.

    Are you just decompiling this, jharp?

  5. #35
    I'll give those methods a try and see. I wanted to keep it simple as an immediate patch. I have to avoid questions on the second topic. They are close but ultimately slower. I'm sure its a bit of a coin toss depending on the data set.

    Jason
    Last edited by jharp; September 29th, 2021 at 18:52.

  6. #36
    Those are helper functions, because the built-in XML functions have some interesting default behaviors that won't work for FG data saving in all cases. The ones jharp found are some of the last that hadn't moved to StringBuilder behaviors. They were originally for a small subset, but are also used for formatted text (which is what I think is the slowdown in your case due to the huge volume of formatted text not seen in simpler modules).

    I hesitate to change them ad-hoc without a lot of testing, because it affects the save files and data. I already tried looking at the built-in XML encoding routines again, but they handle control characters in a way that we can't use. Also, we probably don't want to use String.Replace, because that creates a lot of dangling string resources that have to be garbage collected, creating a different delayed bottleneck. Since StringBuilder is a drop-in change that doesn't change the logic and we have some StringBuilder caching already, I was going to try swapping that in, and see how it affects save time in that campaign.

    However, right now, my hands are busy with some other stuff that has to be done over the next couple weeks, before circling back to any client fixes. Plus, I was deep in a ruleset project before I got pulled away. Thus, why we're hiring. Not enough hands for all the work.

    Regards,
    JPG

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
PF2E Playlist

Log in

Log in