Post

Replies

Boosts

Views

Activity

Reply to AppleScript Safari "do JavaScript" command is extremely slow in Big Sur
Native code supports threads... To support this efficiently... the system blocks the thread and then unblocks it when something interesting happens. Interesting. Thanks for that. Taking a step back, if you poste a copy of your sample I’d be happy to take a look. Use the text attachment feature (the paperclip icon) to avoid clogging up the timeline. Thanks for that. I tested some samples the other day after reading your notes. I got as far as getting an inkling, so your offer is very much appreciated. Sample 1 of 3 - https://developer.apple.com/forums/content/attachment/f7fa2e80-33b1-48e4-b552-cdb8b030d4f0 Sample 2 of 3 - https://developer.apple.com/forums/content/attachment/af1565bc-aaff-4916-a60e-981c0d1c8d35 Sample 3 of 3 - https://developer.apple.com/forums/content/attachment/c40115c6-2d02-42a7-93fc-bb9b2e128d9d
May ’21
Reply to AppleScript Safari "do JavaScript" command is extremely slow in Big Sur
Thank you for the detailed explanation. There's a lot that I'm not quite following yet. This shows that the main thread was sampled 2529 times and: All 2529 backtraces included NSApplicationMain (duh!). Only 2516 included -[NSApplication run]. But all of those also included -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:]. I’ve heavily edited this to highlight the area around _BlockUntilNextEventMatchingListInModeWithFilter. Of the 2529 total backtraces, 2505 included that symbol. And of those, 2494 included ReceiveNextEventCommon + 587 and the remaining 11 included ReceiveNextEventCommon + 284. What's the implication of a larger number -- "2494 ReceiveNextEventCommon" -- followed by the smaller number "11 ReceiveNextEventCommon" What you’re looking for is the thread, or threads, that are not blocked like this, , for example: The samples for the thread are scattered around a bazillion different routines. The samples are concentrated in one routine, or a small set of them, but they are obviously not blocking. I'm imagining a listing that, instead of being hierarchical is more or less flat, repeating over and over again. Is that what you mean? When you say "blocked" and "not blocked" I'm in a JavaScript headspace where synchronous block the next command and asynchronous step aside and let the next steps run, but that might be misunderstanding what you're getting at.
May ’21
Reply to AppleScript Safari "do JavaScript" command is extremely slow in Big Sur
Thanks @eskimo OK followed up on your suggestions -- sent in a Bug report and have a tech support for it as well. Will follow up when I hear back. RE Try this: Use Activity Monitor to see which Safari process is burning all that CPU. Then sample that process (select it and choose Sample Process from the action menu) to see what it’s doing. Tried that in 2 ways: 1 - Watching Safari's subprocesses with Activity Monitor set to View All processes, hierarchically. Only the master app, "SafarI" runs at 100%. All the sub-processes remain around 1% or so.. 2 - Sampling Safari while simultaneously running the AppleScript. Returns a mountain of data, but I don't know how to make sense of it yet. LMK if you have any clues what to look for.
May ’21