hallo

da ich mich seit langem mal wieder mit delphi beschäftige und jetzt mal ein größeres projekt auf die beine stellen wollte kam mir die frage in den sinn:

ist es sinnvoller möglichst alles über einen prozess laufen zu lassen oder wenn möglich alles auf kleine prozesse zu verteilen?
zu betracheten ist dabei die systembelastung, also cpu auslastung, speicherbedarf,...

als kleines bsp.
ich habe ein programm was irgendetwas macht (egal was) und möchte in diese programm eine anzeige integrieren die die aktuelle uhrzeit zeigt. sollte das nun in das eigentliche programm integriert werden oder als eigener prozess laufen und nur grafisch mit dem anderen programm verbunden werden, damit es so aus sieht als ob es teil des programms wäre?

möglicherweise ist das genau ein bsp wo es überhaupt keinen sinn macht, da der nutzen nicht in relation zum aufwand steht, aber darüber kann man ja mal diskutieren

mfg crncpz

die frage ist, ob diese prozesse kommunizieren sollen.
dann wäre es wahrscheinlich sinnvoller mit threads zu arbeiten. ausser sie müssen sehr viel austauschen, dann würden threads mit ihren vielen synchronisationen das system fast blockieren.
wenn sie unabhängig voneinander agieren können ist es wahrscheinlich gescheiter das in eigene programme zu verpacken, damit die auch einzeln aufrufbar (und compilierbar) bleiben.

ich denke das sind die hauptaugenmerke, nach denen sowas entschieden werden könnte/sollte

mfg
Fabs

Die Probleme, die es in der Welt gibt, sind nicht mit der gleichen Denkweise zu lösen, die sie erzeugt hat.
Albert Einstein

so ähnlich hab ich mir das schon gedacht, für keine oder gelegentliche kommunikation könnte es durchaus von vorteil sein, aber um bei dem beispiel der uhr zu bleiben müsste man das programm deutlich abspecken, für eine solche banale funktion sind mir die üblichen 300kB delphi programme zu groß.

wie sieht es aber zum bsp mit dem speicherbedarf aus wenn ich 10 einzelne programme laufen lasse brauchen die dann mehr speicher als ein programm was alle 10 funktionen macht?

definitiv ja.

Einen gewissen overhead hat man immer, um gewissen Libraries wird man nicht herumkommen.

Da wäre ein Plugin-System mit eigenen Threads sicherlich besser.

crncpz hat folgendes geschrieben:

... für eine solche banale funktion sind mir die üblichen 300kB delphi programme zu groß ...

ich kann mir nicht vorstellen, dass es drunter überhaupt sinnvoll geht.

sonst schließe ich mich hazard999 an (war zu langsam, es selbst (viel länger) auszuführen )

mfg
Fabs

Die Probleme, die es in der Welt gibt, sind nicht mit der gleichen Denkweise zu lösen, die sie erzeugt hat.
Albert Einstein

passiv hat folgendes geschrieben:

ich kann mir nicht vorstellen, dass es drunter überhaupt sinnvoll geht.

ich dachte irgendwo hätte ich das mal gelesen das es möglich ist delphi programme ein wenig ab zu specken. weis aber nicht mehr wo ich das gefunden hatte

ein plugin system wäre sicher eine gute und sinnvolle lösung, ich hab zwar ideen wie man so etwas umsetzen könnte, aber wie man es richtig macht hab ich keinen plan. toll wäre es wenn man das so machen könnte wie ein deskband in der taskleiste oder so ähnlich.

wo ich mir nicht sicher bin ist das es über ein pluginsystem unbedingt weniger speicherbedarf hat, schließlich muss das im eigentlichen programm ja irgendwie implementiert werden?

mfg crncpz

Das kleinste Delphi-Programm von dem ich weiß, ist eine extrem abgespeckte Anwendung, mit so wenig Compiler-Magic in der System.pas, dass der Compiler die System.pas gerade noch akzeptiert. Programmgröße: 5 KB.

Ohne Modifikationen der System.pas und unter Nutzung der WinAPI bekommt man ein leeres Fenster mit 16 KB hin ...

Zu der Diskussion, was abzutrennen ist und was nicht, bzw. was man trennen sollte und was nicht:
Alles, was Funktionalität einer Teilkomponente darstellt, sollte auch in dierser Komponente zusammengefasst werden. Ist diese Funktionalität in sich abgeschlossen, und wird durch fremde Komponenten genutzt werden, sollte sie abgetrennt werden (z.B. ein Lizenz-Server für eine Anwendung). Erweitert eine Komponente die Funktionaliät, sollte die Realisierung über ein Plugin erfolgen. Abgeschlossene Funktionalität, die nicht noch einmal extern (z.B. nicht als Kommandozeilen-Client) angeboten werden soll, sollte im Hauptprogramm eingebunden werden, sofern diese regelmäßig benötigt wird; ansonsten als Plugin (um eine Konfigurierbarkeit zu ermöglichen).

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.