Wieso lassen so viele Programme den Benutzer so lange warten?

[knivil]

Eisflamme schrieb:

Hm und wie setzt man Asynchronität ohne Multithreading um?

Schon mal was von DMA gehoert? Laeuft asynchron genau wie viele andere Prozesse auf dem PC ganz ohne Multithreading, eben weils von der Hardware unterstuetzt wird.

[Eisflamme]

Ja okay, das sind für mich halt so Spezialfälle. Wenn ein Socket das halt kann, weil der Netzwerkadapter das übernimmt, ist das für mich sowieso in gewisser Weise eine Blackbox, d.h. ob der jetzt einen extra Prozess/Thread nimmt oder die Hardware halt hineinschlüpft, ist mir persönlich natürlich egal.

Ich würde ja auch keine Sockets in extra Threads auslagern, jedoch sind die zeitaufwendigen Rechenoperationen, welche das GUI blockieren, ja eben oft nicht im Vorhinein asynchron, sonst würde ich ja auch nicht schade finden, dass bestimmte Programme (temporär) einfrieren.

[rapso]

mir kommt es eh vor, dass die meisten stalls und wartereien nicht viel mit cpu arbeit zu tun hat. ich habe lange nachdem VS.Net raus war noch VC6 benutzt, weil es immer responsiv war und die ganzen .NET versionen gerne ewig zum laden/beenden brauchen und auch manch einfacher klick (manchmal nur das hauptmenue) stallt ewig.
- seit VS2010 ist es um eonen besser geworden - Wenn man sich dann die CPU auslastung anschaut, ist die cpu idle. Manchmal ist es nur in source control plugin, ein code highlighter (intellisense ) oder windows speicher verwaltung (die auf die HDD wartet) die ganz visual studio blockt.

Ich finde warten ist das toedlichste fuer meine arbeit, lieber debugge ich memory corruptions als nichts tun zu koennen. Besonders schlim sind wartezeiten von 5s-45s (hab ich mal in nem paper gelesen), da die intervalle zuwenig sind um was anderes zu tun, aber lang genug um das hirn auf "pause" zu stellen, sodass man anfaengt ueber ganz andere dinge zu denken oder doest und garnicht bemerkt, dass das worauf man wartete schon lange fertig ist.

wann immer ich solche blocker sehe, optimiere ich an jedem moeglichen ende damit es besser wird. z.B.
-meine engine mit ca 100k+ loc sammt shadern etc. hat eine rebuild zeit von <5s
dafuer hab ich unity builds eingefuehrt, so ziemlich alles (soweit es geht) was header included haben ist forward declared. viel arbeit die in templates gemacht wurde (hashes, adapter fuer scripting,...) ist jetzt ein prepass mit einer .exe (der in den build process von visual studio integriert ist, also dependencies etc. funzen). Ich habe zudem viel vom code refactored sodass ich alle zeit lang geschaetzt jeweils 10% vom code reduzieren/entfernen konnte.
-mein 3d editor startet in <1s, theoretisch konvertiert er daten von mehreren 100MB (z.b. texturen von tga ->dxt/pvrtc/atitc), dabei muss ich oft auf externe libs zugreifen die man nicht wirklich parallelisieren kann, deswegen cache ich alles und habe eine interne dependency verwaltung.
wenn z.b. jemand in include von einem script file aendert, oder von einem shader, oder das format von einer textur abaendern will, wird alles abhaengige zur laufzeit vom editor oder spiel abgeaendert/neugeladen.
ich hatte vorher keinen 3d editor (und ich hasse gui coden:( ), aber der workflow von einem cct->export->converter->gamestart ist zu schlecht um irgendwie ordentlich arbeiten zu koennen.

ich glaube viele programme sind so 'schlecht', weil die entwickler schlichtweg aufgegeben haben zu versuchen zu verstehen was vor sich geht, weil sie oft die ganze verantwortung an externe libs abgegeben haben auf deren performance sie eh keinen einfluss haben.
Ich bewerte deswegen progamme/spiele anhand ihrer ladezeit. sowas wie God Of War kann man von anfang bis ende durchspielen ohne jemals einen ladebalken zu sehen, andere spiele wie z.B. http://www.youtube.com/watch?v=Lhib8lDknBM sind wenn man einfach nur spielen moechte.