rubs Posted March 7, 2019 Author Share Posted March 7, 2019 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 More sharing options...
Mark Ingram Posted March 7, 2019 Share Posted March 7, 2019 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 More sharing options...
adirusf Posted March 16, 2019 Share Posted March 16, 2019 (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. 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 March 16, 2019 by adirusf I rushed a little bit debraspicher 1 Link to comment Share on other sites More sharing options...
Mark Ingram Posted March 17, 2019 Share Posted March 17, 2019 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? debraspicher 1 Link to comment Share on other sites More sharing options...
adirusf Posted March 18, 2019 Share Posted March 18, 2019 Yes i can reproduce each time. I can send you the file. My configuration I7 3770, windows 10 pro build 18356 MattP 1 Link to comment Share on other sites More sharing options...
Mark Ingram Posted March 18, 2019 Share Posted March 18, 2019 Yes please @adirusf! It would be great to solve this issue. adirusf 1 Link to comment Share on other sites More sharing options...
adirusf Posted March 18, 2019 Share Posted March 18, 2019 ... Link to comment Share on other sites More sharing options...
Mark Ingram Posted March 20, 2019 Share Posted March 20, 2019 @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. debraspicher 1 Link to comment Share on other sites More sharing options...
adirusf Posted March 22, 2019 Share Posted March 22, 2019 True, same behave, didnt notice before. Link to comment Share on other sites More sharing options...
Mark Ingram Posted March 22, 2019 Share Posted March 22, 2019 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 More sharing options...
adirusf Posted March 22, 2019 Share Posted March 22, 2019 If I export only as .png my CPU wont go above 50%. Untitled 1.avi debraspicher 1 Link to comment Share on other sites More sharing options...
Petar Petrenko Posted March 27, 2019 Share Posted March 27, 2019 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 More sharing options...
Mark Ingram Posted March 27, 2019 Share Posted March 27, 2019 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. Alfred, Chris J, walt.farrell and 3 others 6 Link to comment Share on other sites More sharing options...
Staff Ben Posted March 28, 2019 Staff Share Posted March 28, 2019 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. matt.baker, Alfred and walt.farrell 3 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 More sharing options...
v_kyr Posted March 29, 2019 Share Posted March 29, 2019 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. SrPx and Alfred 2 ☛ 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 More sharing options...
nezumi Posted March 29, 2019 Share Posted March 29, 2019 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. Alfred and lepr 2 Link to comment Share on other sites More sharing options...
Petar Petrenko Posted March 29, 2019 Share Posted March 29, 2019 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 More sharing options...
Recommended Posts