Jump to content
You must now use your email address to sign in [click for more info] ×

Slow startup (all Affinity apps)


Recommended Posts

I notice that when I start my computer and open an affinity app it takes about 40 seconds to load. if I close the app but keep the computer on then reopen the app again it takes about 4 seconds to load. It is the same for all affinity apps

Mac running Big Sur

Link to comment
Share on other sites

  • 2 weeks later...
  • Staff

@rudluc & @MrMacvos

Welcome to the Serif Affinity forums :) 

This is not a "bug" as such, it is a consequence of Apple’s ‘YARA’ malware scanning of the application, which is new and seems to object to our JIT runtime flag, which we need for compatibility reasons.

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

  • Staff

I agree it is very annoying, and not something we have chosen in any way. If we can find a way to avoid the checks happening we will implement it we have already tried a number of things, but this is also currently with Apple to see if they can make their YARA system less strict (not rechecking if our files have not changed since last time they "checked" them) 

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

Well, it may be a slight bit annoying to some, but Photo, Designer, and Publisher are definitely worth a few seconds wait.   Once open, they WHIZ!


24" iMAC Apple M1 chip, 8-core CPU, 8-core GPU, 16 GB unified memory, 1 TB SSD storage, Ventura 13.6.  Photo, Publisher, Designer 1.10.5, and 2.3.
MacBook Pro 13" 2020, Apple M1 chip, 16GB unified memory, 256GB  SSD storage
,  Ventura 13.6.   Publisher, Photo, Designer 1.10.5, and 2.1.1.  
 iPad Pro 12.9 2020 (4th Gen. IOS 16.6.1); Apple pencil.  
Wired and bluetooth mice and keyboards.9_9

Link to comment
Share on other sites

Well, thanks for the response. Waiting for apple to fix something or change, if its related to their security can take years :). I am wondering, why other apps from other vendors do not have the issue. And even the ones which are not on the app store...perhaps, if i have a version which is not from the app store ? May that work?

Link to comment
Share on other sites

3 hours ago, PeterSvancar said:

Waiting for apple to fix something or change, if its related to their security can take years :). I am wondering, why other apps from other vendors do not have the issue.

I'm not 100% on this, but generally "JIT" in computing means that there is some form of compilation of the "code" immediately prior to execution. In Java for example you would distribute a byte-code package that is then compiled at run time to the target system (allows one code base to run on any system).

If that's something along the lines of what is happening here, then I can understand the security check - the app contents need checking to ensure that nothing out of place is there, as it's not a "fixed" piece of software, but is built on the fly. I'm not sure how Apple could mitigate this, if at all.

Other apps are pre-compiled to the destination architecture so don't have anything that requires this security check.

Just my guesses based on some prior use of JIT code, not saying this is any any way correct though. 

Link to comment
Share on other sites

1 hour ago, BofG said:

I'm not 100% on this, but generally "JIT" in computing means that there is some form of compilation of the "code" immediately prior to execution. In Java for example you would distribute a byte-code package that is then compiled at run time to the target system (allows one code base to run on any system). ...

Plain native MacOS apps aren't JIT compiled, they don't run and aren't executed inside a virtual machine, or are build/compiled in an intermediate bytecode format at all, which is then during execution time compiled into native CPU machine code. - Instead the MacOS apps do contain multiple architecture CPU related machine code (so called FAT binaries) and during an apps startup the underlaying host CPU architecture is determined and that portion is executed from the apps multi-CPU-architecture binary context.

Multi-architecture (or FAT) binaries usually don't have such a big time lag when executed, which you also can test by stripping an unneaded CPU architecture from a FAT binary app via the help of the "lipo" tool etc. and then analyze how that then behaves in terms of startup time lag.

I think the startup time lag has more to do with the MacOS's security implementation (signing/signature, notarization ...) mechanisms for apps here. Since MacOS contains authorization and malware detection mechanisms which do check/scan every app during it's startup (similar like build-in virus scanner and firewall mechanisms on Win). So the whole is more a matter of this and that somewhere during this whole process, some processing takes an unnecessary long time to complete then!

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

On 4/30/2021 at 12:45 PM, Patrick Connor said:

seems to object to our JIT runtime flag

@v_kyr interesting insight, MacOS isn't something I've ever developed for. Given what you've said, what does the "JIT" mentioned by Patrick refer to? Is it possible to include a library as a source (or some intermediate form) and have it compiled to the target architecture at run time? Can't imagine what JIT would mean unless it's along those lines.

Link to comment
Share on other sites

56 minutes ago, BofG said:

@v_kyr interesting insight, MacOS isn't something I've ever developed for. Given what you've said, what does the "JIT" mentioned by Patrick refer to? Is it possible to include a library as a source (or some intermediate form) and have it compiled to the target architecture at run time? Can't imagine what JIT would mean unless it's along those lines.

Usually JIT compiling is more related to the context of VM based prog languages, like Java and C# etc., where you need and have a host systems CPU based VM runtime environment in order to execute the intermediate bytecode into the hosts native machine code. Though some Interpreter languages also do use and offer similar JIT like concepts.

AFAI understood it @Patrick Connor probably means with ...

Quote

... Apple’s ‘YARA’ malware scanning of the application, which is new and seems to object to our JIT runtime flag ...

... the following MAP_JiT flag with JIT runtime flag related to ...

... and in such a context ...

Quote

MacOS 10.14 will allow apps to opt-in to an "Enhanced Runtime" allowing the OS to enforce that all executable code pages match 
their on-disk signature. This includes an exception apps can use that allows pages mapped with the MAP_JIT flag to be executed. 
Without the MAP_JIT support in the JS engine, we would still be able opt-in to the Enhanced Runtime, but we'd have to disable all 
code signing protection using the com.apple.security.cs.disable-executable-page-protection option. ...

See also:

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

  • 2 weeks later...

Well... This problem is still not solved, and we are months later...

There are serious software QA issues as performance regressions are becoming more and more common on all Affinity apps on Mac (apparently on Win, too). In fact, I enjoy less and less using Affinity apps, particularly when I have to tell my customers to wait a little bit more because of bugs in Publisher while merging data, for example. Having to make them accept deliverables using Affinity formats instead of industry standards is already difficult enough.

I use other resource intensive apps for engineering, and none of them are subject to the performance problems mentioned here. So, what is Serif doing wrong ?

Would it be hard to keep your users informed on a specific development blog for example, so it would possible to know on what you're working instead of just hoping for these bugs to be solved ? Do you have a public bug tracking system ? Would you publish a roadmap so we know what to expect and when ? This black box style of development is so outdated...

As new versions were published, I installed them hoping for better performance. But new bugs appeared and I can't downgrade to previous versions that used to work better (App Store versions).

In short, I am not sure where my honeymoon with Affinity products is going...

Link to comment
Share on other sites

6 hours ago, Delden said:

I use other resource intensive apps for engineering, and none of them are subject to the performance problems mentioned here. So, what is Serif doing wrong ?

In a different thread they said this slow start up is down to them embedding a browser in the app, which is used for the welcome screen and user account. I believe it allows them an easy way to keep those parts updated, as they can just put fresh html content on the server and the app will fetch and display it.

The new Apple malware check is more intrusive in this use case as the app (via the embedded browser) has a JavaScript engine and can execute arbitrary code.

Link to comment
Share on other sites

5 hours ago, BofG said:

In a different thread they said this slow start up is down to them embedding a browser in the app, which is used for the welcome screen and user account. I believe it allows them an easy way to keep those parts updated, as they can just put fresh html content on the server and the app will fetch and display it.

The new Apple malware check is more intrusive in this use case as the app (via the embedded browser) has a JavaScript engine and can execute arbitrary code.

Interesting, indeed. 

Speaking of a browser that can execute arbitrary JavaScript code, Firefox should fall in this category, but it's not the case. Regarding embedded browsers and much more "dangerous" code, I use Jetbrains's software for development / engineering and these products are not facing these problems either. They have connected welcome screens, plugins update mechanisms, online code and tools installers, remote debuggers, and so on... If you look in the forums, Win users are experiencing performance problems, too.

At this stage, what's more disturbing for me is the lack of visibility on what they are working on. As I said, a public bug tracker would help both the users to know what they're doing and the devs to receive more detailed and specific information to help. This is disturbing because the users started to experience these problems more or less 8-9 months ago (we are almost in June) and the communication is inexistant, like if there is no problem at all. You have to actively dig into the forums and search for similar problems and this is not OK. It would be in an open source community project, but here we have commercial products aimed at professional users.

Moreover, the software QA is apparently not catching regression bugs in both performance and functional aspects. I totally understand that the staff is doing its best, but it's not what's most important : get bugs fixed first, and check for every possible regressions before adding new functions. And give all users a warning on web site in the style "We have currently a problem with X, that was not present in version X -1, so don't update for now if this is important for you". Or more simply don't publish a buggy version.

As I said, having customers to accept non Adobe deliverable files is difficult enough. Even if they are open to support a smaller company like Serif, in the end they want a deliverable at the deadline, not excuses because something that was working previously is not working anymore.

Link to comment
Share on other sites

18 minutes ago, Delden said:

these products are not facing these problems either

I'm not sure on the specifics, I've just pieced together this from what little has been said and some of the developer info from Apple that mentions JavaScript engines and that JIT flag. It's a pity there isn't more detailed official information.

 

20 minutes ago, Delden said:

Or more simply don't publish a buggy version

Wholeheartedly agree with this. I think the test plan is somewhat ad-hoc at best. I've been using the software long enough to have seen a few of the major releases, and I now double check every now and then to ensure automatic updates are not enabled.

Link to comment
Share on other sites

2 minutes ago, BofG said:

Wholeheartedly agree with this. I think the test plan is somewhat ad-hoc at best. I've been using the software long enough to have seen a few of the major releases, and I now double check every now and then to ensure automatic updates are not enabled.

End users should not be the beta testers. As Serif releases beta versions, I already installed some in the past. Just using a beta version is not enough to find bugs, because it's impossible to test every possible usage patterns and the available time is surely not infinite (and not free). Automatic tests are made just for this purpose, even if they can't test every possible code paths, either. But at least they can test for thousands or millions paths overnight and it is generally enough to spot bugs or regressions.

What's frustrating in this specific case, it's that all products are affected by a bug on a completely non-essential functionality (regarding only the slow startup case). 

In the end, how can you know that a specific bug has been corrected before updating ? If at least there was a public bug tracking system to allow users to know if a specific problem is solved.

Link to comment
Share on other sites

4 hours ago, Delden said:

In the end, how can you know that a specific bug has been corrected before updating ?

The other side of that is how to know if a bug exists that affects all users, only those using a specific OS version, only affects those using certain drivers or some third party add-on that interferes with Affinity, or what.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Both good points. I've held off updating to 1.9 because I don't know what new bugs await and not sure if the little annoyances from before are fixed. I've decided it's better the devil you know.

There is a "known issues" sticky, but it's far from comprehensive and only lists things that they have fixed (as in introduced in 1.9 and fixed).

A public bug tracker could have it's downsides, more pressure on the no doubt already stretched team, but I think it would be a positive step for the users.

Link to comment
Share on other sites

8 hours ago, Delden said:

Interesting, indeed. 

Speaking of a browser that can execute arbitrary JavaScript code, Firefox should fall in this category, but it's not the case. Regarding embedded browsers and much more "dangerous" code, I use Jetbrains's software for development / engineering and these products are not facing these problems either. They have connected welcome screens, plugins update mechanisms, online code and tools installers, remote debuggers, and so on... If you look in the forums, Win users are experiencing performance problems, too.

I think the Rust based Firefox and Jetbrains Java based IDEs don't reuse Apple's Webkit etc. APIs here in the same sense as Affinity does. Mozilla and Jetbrains for sure do have and use their own implementations for such browser based tasks and only rely for the common app signature and notarization on the needed Apple guidelines/procedures. Both Firefox & Jetbrains also have good/foolprove working own update mechanisms for their desktop software, which isn't MAS/sandbox dependent. - Only Firefox for iPad is more MAS controlled here.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

2 hours ago, PeterSvancar said:

i have now updated to the latest big sur and looks like the problem is still there, auto GPU switching doesnt work either

What are you doing to me? I got an email notification for this thread in which you said:

Quote

i have now updated to the latest big sur and looks like the problem is gone

I updated immediately... only to see the problem has not changed at all. Then I open this thread and see you changed your answer. This is advanced trolling.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.