Jump to content
rubs

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.

Share this post


Link to post
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).

Share this post


Link to post
Share on other sites
Posted (edited)

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

Share this post


Link to post
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?

Share this post


Link to post
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?

Share this post


Link to post
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.


Windows 10 x64 Pro
Dell Inspiron 7559 i7
Intel Core i7-6700HQ (3.50 GHz, 6M )
16GB Dual Channel DDR3L 1600MHz (8GBx2)
1TB HDD + 128 GB SSD Hard drive
UHD (3840 x 2160) Truelife LED- Backlit Touch Display
NVIDIA GeForce GTX 960M 4GB GDDR5

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
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.7.1 ◆ Affinity Photo 1.7.1 ◆ OSX El Capitan

Share this post


Link to post
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.

Share this post


Link to post
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. :)


Windows 10 x64 Pro
Dell Inspiron 7559 i7
Intel Core i7-6700HQ (3.50 GHz, 6M )
16GB Dual Channel DDR3L 1600MHz (8GBx2)
1TB HDD + 128 GB SSD Hard drive
UHD (3840 x 2160) Truelife LED- Backlit Touch Display
NVIDIA GeForce GTX 960M 4GB GDDR5

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | 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.