Program för att se vad som flaskar

Hej alltför ofta sitter jag med något program som går ubersegt, ibland ser man väldigt tydligt i windows resource manager vad som flaskar, dessutom kan man kolla på ens grafikkortsprogram och se hur hårt denna jobbar.

Men väldigt ofta ser jag att processorn kanske ligger på 30% belastning, enstaka kärna sticker upp till 40%, ram så har man bara använt 1/3 del, hårddisken utnyttjas knappt, likaså grafikkortet. Ändå tar det kanske 1h att göra en export från ett program och man funderar på vad flaskhalsen är?
-Jag har stött på detta på ett 30tal datorer från med Win 3.1-> windows server 2016 och använt olika programvaror, så nej det är ej datorn som det är fel på.

Nå frågan är vet någon något bra program för att analysera vad det är som flaskhalsen i sin dator när man kör viss belastning på den?

Och då är följdfrågan, om det nu en export tar 1h att göra. Vilken hårdvara ska jag då uppgradera för att göra exporten snabbare?
Eller spelar det ingen roll vad för hårdvara jag skaffar?
Nu är min fråga generell, då jag hur ofta som helst i väldigt många program känner att det går väldigt segt, men jag ser ingen komponent som bottnar. Och känna att det går segt är ingen inbindning utan operationer kan ta flera minuter att göra.
Alltså man klickar på en knapp och får vänta någon minut på att det som utförs ska utföras.

Det är blandat alltifrån kommersiella till egenskapade. Bland egenskapade så är det t.ex när ett tusentals databasfiler ska uppdateras med information. Det blir en hel del sql-anslutningar till dessa.

Min misstanke med dessa programmen är att de använder sig av väldigt massa komponenter, där det skapas anslutningar åt det ena och det andra hållet. Jag är dock tveksam på att det är inbyggda delayer som gör att det går segt, men att det är minibegräsningar som kanske ej visas i taskmanagern för att de är så korta.

För att ta ett exempel att läsa in en megastor IFC fil i Autodesk Revit tog på jobbdatorn ca 12h eller något. (jag var ej där)
På min privata dator fixade jag samma fil på runt 4h.

På ingen av datorerna låg någon komponent hela tiden i max, men ändå gick det snabbare på min privata. Frågan är varför?
Jobbdatorn: i7 3770k 8GB ram, uberkass gpu, billig ssd
Privata: i7 7700K 64GB ram, 1060 6 GB, 960 Evo m.2

*edit*
Men som sagt jag upplever detta slöhet i väldigt många program, saker tar hur lång tid som helst att utföra, men man ser inget som bottnar.
Det generella med programmen är dock att de ofta inte är mainstrem och att de säkerligen drar ner på optimeringar för att få pengarna att räcka till att implementera funktionen. Ett program som kanske säljs i 10 000 exemplar istället för 10miljoner har ju mindre pengar för prestandaoptimeringar.

*edit2*
Ett annat kommersiellt program, så är det en massa objekt på sidor. Dessa objekt är uppbyggda av olika databasefiler av olika slag. När man ska uppdatera och bygga om säg 2000 såna sidor så kan det ta några timmar, jag vill få ner tiden, men jag ser ingen hårdvara som begränsar.
Nedanför visas hur en sida kan se ut och det är några tusen såna som ska byggas om:
http://www.osg.se/wwjl/Var/Processbild_1/driftkort.gif

Ok, tackar för hjälpen. Jag upplever som sagt inte problemet i ett program utan flera där dessa körs på helt olika maskiner.

Tackar för informationen ja det är nog jättesvårt att göra djupdykningar i vad som gör saker går slött i andra tillverkares programvaror. Liksom att Autodesk Revit är slö att importera IFC filer är en fråga för Autodesk att utreda, det är inget som vi vanliga folk lätt kan vara på. (Autodesk är de som gör Autocad, maya etc, de är inget litet bolag)

Nu kan jag ej så lätt byta ut någon hårdvara på just min datorn(finns inte så extremt mycket snabbare att köpa), men jag stöter på problemet överallt. Där man i 95% av fallen direkt ser att en kärna ligger i 100%, eller disken maxas etc. Men de där övriga 5% är jag ute efter.

Nu var jag otydligt i min text, men de program där jag kan se flaskhalsen i är inte mitt problem. Utan de program där jag inte ser någon kärna går högt och det annars går segt.

Sedan även om ett program är gjort för att använda 16 kärnor som programmet ovanför som går segt, så kan det ändå vara så att det är en enda kärna som sätter begränsningen för hur snabbt hela programmet känns. Och jag vill påstår att det väldigt ofta är en kärna som begränsar allt, det andra kärnorna kanske ligger i 60%.
Undantaget är vissa operationer som extremt väl skalar, det kan vara inläsning/export av filer som kan vara väldigt enkelt att sprida lasten på.

*edit*
Detta med antal kärnor är komplicerat. Ett program jag använder maxar alla 8 (kärnor +ht) vid inläsning, fler kärnor hade resulterat i att programmet hade startas snabbare, men när programmet väl är igång, så är det två kärnor som ligger långt över alla andra och det är de som begränsar hur snabbt programmet upplevs att använda.

*edit2*
Angående byta program så är det inte alltid så lätt, programmet med bilder jag pratar ovanför kostar över 1 mille i licens för en stor anläggning, lägg till 20 gånger så mycket för att fysisk göra ett systembyte.
Programmet skalar självklart på i princip hur många kluster som helst (inte kärnor utan helt skilda datorer), men det innebär inte att precis alla delar i programmet skalas bra och mycket arbete så är det en enda kärna som sätter begränsningen för hur snabbt något ska gå.

*edit3*
Nedanför en skärmdump på ett taskmanger vid uppstart av ett program, där man i första ögonblick tror att i7 7700K suger med sina 4 kärnor, men när väl datorn är igång så sjunker alla kärnor utan två och 7700K visar vad den går för.

Tackar för råden, ja det finns nog inte bara något bättre program än det inbyggda i windows som jag hade hoppas på. Jag kan förstå att det finns mycket pengar att tjäna i att kunna optimera prestandan, i den bransch Automation där jag jobbar med är det mer kaos.
Tiotals olika aktörer kan vara inne på samma servrer, ingen tar någon hänsyn till att snåla på resurser för någon annan.

Jag gjorde en grymt optimerad driver för ett tag sedan, jag var så stolt, men nu ville de ha utökad funktionalitet och hade jag ej optimerat den så hårt så hade jag nu slippat göra om den från grunden.