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

About the performance improvements


Recommended Posts

 

1 hour ago, Mark Ingram said:

Yep, that is to be expected with the latest performance changes. You will see a higher residual memory usage, even after closing documents.

Hmmm... thanks for letting us know that. So in the long term the app will get slower because of that. I hope you are still investigating the issue to correct this in the near future.

Link to comment
Share on other sites

2 hours ago, rubs said:

 

Hmmm... thanks for letting us know that. So in the long term the app will get slower because of that. I hope you are still investigating the issue to correct this in the near future.

No, the app won't get slower because of that. It is getting slower because of something else. Having a memory footprint doesn't make an application run slower (up to a point, if you use so much memory that you start paging to disk, then you will run slower - but a residual 2GB isn't going to cause these kinds of issues).

Link to comment
Share on other sites

  • 2 weeks later...

Today after several hours of work in the A.D. version 1.7.0.258, the processor has begun to go crazy, look at this gif, strange that after shutting it down the program behaved normally in the sense that A.D. does not consume not even 1% of the processor.

cpu.gif

I followed all the possible steps and came to the conclusion that after I activated CONTINUOS while slices (6 of them) are converted into pdf for print I can barely move the mouse until the process finalizes.

 

Edited by adirusf
I rushed a little bit
Link to comment
Share on other sites

On 3/16/2019 at 4:19 PM, adirusf said:

Today after several hours of work in the A.D. version 1.7.0.258, the processor has begun to go crazy, look at this gif, strange that after shutting it down the program behaved normally in the sense that A.D. does not consume not even 1% of the processor.

I followed all the possible steps and came to the conclusion that after I activated CONTINUOS while slices (6 of them) are converted into pdf for print I can barely move the mouse until the process finalizes.

 

Thanks for that - very interesting. Can you reproduce it each time?

Link to comment
Share on other sites

On 3/20/2019 at 9:01 PM, Mark Ingram said:

@adirusf, is this behaviour different to 1.6? I would expect high CPU usage for a short period, as you've selected 'Continuous Export', so every change you make to the document will export a PNG and PDF of each layer.

 

3 hours ago, adirusf said:

True, same behave, didnt notice before. 

Having said that, we should be aborting the export whenever you change the document. This might be a problem related to the ability to abort PDF export. We'll need to experiment with that. I assume if you disable PDF export it doesn't lock up in the same way?

Link to comment
Share on other sites

15 hours ago, Ben said:

 

Assembler is definetly the best alternative. It is the same as machine code bat with human acceptable syntax. The relationship of the Instructions between assembler and machine code is 1:1, means that one instruction of machine code is equal to one instruction of assembler which is not the case between the machine code and the high level programming languages. If you can't find any advantages of assembler over the programing language(s) you use, the problem is in the programer(s) skills not the language itself.

The problems you found with PhotoLine can easily be addressed to Affinity apps as MikeW mentioned above.

Assembler is definetely the No. 1 choice for fastest and smalest executabile applications.

All the latest releases of Designer, Photo and Publisher (retail and beta) on MacOS and Windows.
15” Dell Inspiron 7559 i7 Windows 10 x64 Pro Intel Core i7-6700HQ (3.50 GHz, 6M) 16 GB Dual Channel DDR3L 1600 MHz (8GBx2) NVIDIA GeForce GTX 960M 4 GB GDDR5 500 GB SSD + 1 TB HDD UHD (3840 x 2160) Truelife LED - Backlit Touch Display
32” LG 32UN650-W display 3840 x 2160 UHD, IPS, HDR10 Color Gamut: DCI-P3 95%, Color Calibrated 2 x HDMI, 1 x DisplayPort
13.3” MacBook Pro (2017) Ventura 13.6 Intel Core i7 (3.50 GHz Dual Core) 16 GB 2133 MHz LPDDR3 Intel Iris Plus Graphics 650 1536 MB 500 GB SSD Retina Display (3360 x 2100)

Link to comment
Share on other sites

1 hour ago, Petar Petrenko said:

Assembler is definetly the best alternative. It is the same as machine code bat with human acceptable syntax. The relationship of the Instructions between assembler and machine code is 1:1, means that one instruction of machine code is equal to one instruction of assembler which is not the case between the machine code and the high level programming languages. If you can't find any advantages of assembler over the programing language(s) you use, the problem is in the programer(s) skills not the language itself.

...

Assembler is definetely the No. 1 choice for fastest and smalest executabile applications.

It absolutely is not. When you've written an application the size of Designer, or Photo, or Publisher, purely in assembler, then please come back and discuss this with me.

We know what assembly is, when to use it, and when not to use it.

This discussion is not helpful to the ongoing beta process, so let's just leave this alone.

Link to comment
Share on other sites

  • Staff
13 hours ago, Petar Petrenko said:

Assembler is definetly the best alternative. It is the same as machine code bat with human acceptable syntax. The relationship of the Instructions between assembler and machine code is 1:1, means that one instruction of machine code is equal to one instruction of assembler which is not the case between the machine code and the high level programming languages. If you can't find any advantages of assembler over the programing language(s) you use, the problem is in the programer(s) skills not the language itself.

The problems you found with PhotoLine can easily be addressed to Affinity apps as MikeW mentioned above.

Assembler is definetely the No. 1 choice for fastest and smalest executabile applications.

Petar - I think it's pretty much established that modern compilers are able to produce much better machine code than a human (generally) would.  With optimisation for speed, the compiler will find the best order for instructions, and sometimes apply a few unexpected tweaks to gain better performance.


So, just being able to write 1:1 instructions is not always the best (if ever), and quite often not faster.   I doubt they will be measuring the cycles used for each op and reordering for maximum speed.  This is just something that is either not possible for humans, or the developer time cost massively outweighs the benefits.

 

Writing assembler for very specific tight code can sometimes yield results, but writing a whole app? It won't be any faster, and potentially slower.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

That's right, nowadays for example C/C++ compilers can optimize and generate very fast execution code. In the past to gain more overall processing speed, higher performance compilers (Metaware, Intel etc.) had to be often used, where the math libs of those were then also often generated via Fortran compilers instead, or portions written in Assembler, in order to get better overall processing speeds for number crunching. - However, today that's no more needed, since C/C++ compilers have much better and cleverer optimization techniques. Even trying to hand optimize specific code here often won't give you better results than what the compiler can generate by itself. Compiler implementations have evolved a lot here over years.

Assembler? Related to that, well it's pretty hard to write complex applications and express algorithms or apply design patterns etc. in Assembler language at all. So from a software engineering standpoint, design and program maintenance in that is a very time consuming task and a nightmare, a route nobody really want's to take when writing complex software. It's also the reason why a lot of higher programming languages exist, the later offer much better abstraction capabilities and language constructs to express even complex tasks in a managable manner.

 

☛ 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 3/27/2019 at 1:42 PM, Petar Petrenko said:

Assembler is definetely the No. 1 choice for fastest and smalest executabile applications.

Here is crazy idea. Since nobody really cares about your coding classes here (and most definitely they will not start re-writing Affinity package because random dude on internet thinks they should) - why don't we just concentrate on apps and leave the coding to the coders who are making them?

-----------------------------

Personally I cant wait till GPU acceleration hits Windows version. I know its a lot of work, I know its complicated because of multiple hardware variations etc. I'll wait but I am eager to see it and I hope work is being done on it (well now you are probably fixing 1.7 but hope it is planned anyways).  I don't care if you write it in Basic or Logo - as long as it works. And if it doesnt? Hey, you can always ask some random dude on internet. They know best.

Link to comment
Share on other sites

1 hour ago, nezumi said:

Here is crazy idea. Since nobody really cares about your coding classes here (and most definitely they will not start re-writing Affinity package because random dude on internet thinks they should) - why don't we just concentrate on apps and leave the coding to the coders who are making them?

-----------------------------

Personally I cant wait till GPU acceleration hits Windows version. I know its a lot of work, I know its complicated because of multiple hardware variations etc. I'll wait but I am eager to see it and I hope work is being done on it (well now you are probably fixing 1.7 but hope it is planned anyways).  I don't care if you write it in Basic or Logo - as long as it works. And if it doesnt? Hey, you can always ask some random dude on internet. They know best.

Of course. More brains, more pains. :)

All the latest releases of Designer, Photo and Publisher (retail and beta) on MacOS and Windows.
15” Dell Inspiron 7559 i7 Windows 10 x64 Pro Intel Core i7-6700HQ (3.50 GHz, 6M) 16 GB Dual Channel DDR3L 1600 MHz (8GBx2) NVIDIA GeForce GTX 960M 4 GB GDDR5 500 GB SSD + 1 TB HDD UHD (3840 x 2160) Truelife LED - Backlit Touch Display
32” LG 32UN650-W display 3840 x 2160 UHD, IPS, HDR10 Color Gamut: DCI-P3 95%, Color Calibrated 2 x HDMI, 1 x DisplayPort
13.3” MacBook Pro (2017) Ventura 13.6 Intel Core i7 (3.50 GHz Dual Core) 16 GB 2133 MHz LPDDR3 Intel Iris Plus Graphics 650 1536 MB 500 GB SSD Retina Display (3360 x 2100)

Link to comment
Share on other sites

×
×
  • 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.