Wird der gesamte Code auf objektorientiert geändert, um die Speichernutzung größer oder kleiner zu machen?

Question

Es gibt ein in PHP geschriebenes Projekt, das einfach nur prozedural ist ... Schritt für Schritt, DB-Funktionen aufzurufen, die Ausgabe zu verarbeiten und auszudrucken. Und dann wird es vollständig objektorientiert geändert - es gibt ein Singleton für das App-Objekt, und verschiedene Funktionen werden über das App-Objekt aufgerufen.

Jemand behauptet, dass die Speicherauslastung oder der Footprint auf dem Server geringer ist. Wäre das der Fall? Ich dachte, prozedurale verwendet oft nur die minimale, während objektorientierte Programmierung mit verschiedenen Design-Muster in der Regel mehr Dinge als benötigt instanziiert, oder einfach nur Objekte haben, während prozedurale in der Regel nur das nackte Minimum haben.

Wird also die Änderung des gesamten Codes auf objektorientiert die Speicherauslastung auf dem Server kleiner?

Answer 1

Es wird wahrscheinlich mehr machen, aber es gibt wirklich keine Möglichkeit zu sagen. Wenn sich Ihr Code auf eine OOP-Weise verbessert, kann es weniger sein. Es gibt keine direkte Korrelation zwischen dem verwendeten Speicher und dem Vorhandensein von Objektorientierung. Im Allgemeinen benötigt objektorientiert mehr Speicher, aber nur, wenn beide Codes gleich gut geschrieben sind, und das ist fast nie der Fall.

Gibt es einen Grund, warum diese Anwendung aktualisiert wird, um objektorientiert zu sein? Du weißt, dass es nicht das eine oder das andere ist, du kannst Teile mischen und kombinieren ... OOP ist keine Wunderwaffe.

Answer 2

Ihre Frage klingt für mich wie folgt: Wir haben eine nicht-taugliche Code-Basis, wird es in Java neu schreiben es schneller machen?

Zuerst müssen Sie das Problem identifizieren: ist Ihr Code unlesbar und/oder schwer zu warten oder ist die Laufzeit Ihres Programms zu groß? Dies sind zwei vollständig verschiedene Probleme.

Wenn Sie eine Codebasis haben, die schwer zu warten ist (es klingt wie Sie), lösen Sie das nicht, indem Sie den Code mit einem anderen Paradigma umschreiben. Warum ist der Code nicht lesbar? Schreiben die Entwickler unlesbaren Code, wird das Umschreiben in Java oder C# Ihnen nur objektorientierten, nicht lesbaren Code geben. In diesem Fall müssen Sie die Fähigkeiten Ihrer Entwickler verbessern (stellen Sie bessere ein, erziehen Sie die vorhandenen, etc.).

Wenn Sie ein Problem mit dem Speicherbedarf haben, sollten Sie sich diesem wie jedes andere Leistungsproblem nähern. Zuerst Maßnahme, dann einige Optimierung (schreiben Sie ein Stück Code, um es mehr Speicher effizienter zu machen), und dann wieder messen. Das Messen vor und danach ist wichtig, um sicherzustellen, dass Sie die Dinge nicht schlechter machen. Und glauben Sie mir, selbst sehr gute Programmierer machen diesen Fehler.

Answer 3

Die Antwort ist sowohl Ja als auch Nein.

Durch den Wechsel zu einer objektorientierten Architektur können Sie den Speicherbedarf reduzieren, aber wenn und nur wenn der Code effizienter ist.

Gerade PHP ohne irgendwelche Funktionsaufrufe oder Objektaufrufe ist ziemlich schnell. Sobald Sie mit Funktionsaufrufen oder Objektaufrufen beginnen, beginnen die Dinge viel langsamer.

Von A Python Vs Ruby Vs. Python Benchmark eine OO-Strategie für eine inkrementelle Schleife dauerte 3,7079 Sekunden, funktionsorientierte dauerte 4,3501 Sekunden, und die Verwendung weder 0,6164 Sekunden. Eine einfache "Hello World" -App mit OO vs. Procedural Vs. Weder eine 4.1248 Sekunden vs. 3 yeleded.7656 vs 0,9309 Sekunden.

Je nachdem, was Ihr Code macht und wie er es macht, könnten Objekte sowohl schneller als auch langsamer, speicherintensiver oder weniger speicherintensiv sein oder auch nicht.

Answer 4

Und dann wird es geändert völlig objektorientiert - gibt es eine Singletons für das App-Objekt, und verschiedene Funktionen werden durch das App-Objekt aufgerufen.

, die tatsächlich wie so ziemlich das Gegenteil von „völlig objektorientiert“ klingt. Dies deutet auf eine Ebene des Verständnisses dessen hin, was "objektorientiert" bedeutet, was höchstwahrscheinlich NICHT zu einem reduzierten Speicherbedarf führen wird.

Im Allgemeinen wird das Design einen weitaus größeren Einfluss auf den Speicherbedarf als das Programmierparadigma haben, obwohl es wahrscheinlich ist, dass objektorientierte Apps tendenziell einen größeren Footprint haben.

Answer 5

Speicherauslastung ist nicht der Vorteil von OO. Der Vorteil von OO ist, dass der Code wartungsfreundlicher wird. Wenn Sie keine Leistungsprobleme haben, müssen Sie nicht nach Möglichkeiten suchen, effizienter zu arbeiten.

Answer 6

Zusätzlich zu den anderen Kommentaren möchte ich sagen, dass OO hilft, Redundanz zu reduzieren ... was Ihren Code effizienter machen und den Speicherbedarf reduzieren könnte. Natürlich hat OO mehr Overhead, sollte aber in größeren Projekten effizienter arbeiten.

Answer 7

Leider habe ich meine Tests auch gemacht. Ich habe die Geschwindigkeit getestet, und es ist ungefähr das Gleiche, aber als ich nach der Speicherbelegung von memory_get_usage() in PHP suchte, sah ich eine überwältigend größere Zahl auf der OOP-Seite.

116.576 Bytes für OOP zu 18.856 Bytes für prozedurale. Ich weiß "Hardware ist billig", aber komm schon! 1.000% mehr Nutzung? Entschuldigung, das ist nicht optimal. Und da so viele Nutzer gleichzeitig auf Ihre Website zugreifen, bin ich mir sicher, dass Ihr Arbeitsspeicher einfach brennen würde oder ausgeht. Liege ich falsch?

Grundsätzlich, was ich von all meinen OOP-Fans höre ist, dass ... Sie mehr Ressourcen verwenden werden, wird es genauso schnell wie gut geschriebene prozedurale Funktionsaufrufe sein, aber es wird besser für große Projekte und multi sein -Entwickler-Umgebung. Ein Gleichgewicht muss gefunden werden.

Mehr Devs (schlampig Devs) und größerer Standort

Con: Mehr RAM für Ihre Anwendung verwendet.

Pro: Leichter zu pflegen den Code unter vielen über die ganze App.

Ein Entwickler mit einer einfachen Website

Con: Wenn Ihre Website wächst, oder startet viele Entwickler enthalten, die Entwicklung könnte etwas langsamer sein, wenn Ihr prozeduralen Code saugt.

Pro: Niedriger RAM, etwas schnellere Geschwindigkeit. Wenn Ihr Code richtig geschrieben ist (und nur gute Entwickler können das tun - haha), wird Ihr Code genauso einfach zu pflegen sein.

In den RAM-Kriegen gewinnt Prozedural. In den Wartbarkeitskriegen gewinnt guter Code.;)

OOP-Lüfter sagen, dass OOP sauberer ist. Ich habe einen wirklich unordentlichen OOP-Code gesehen, und dann habe ich einen REAL CLEAN-Verfahrenscode gesehen, geschrieben von Entwicklern, die großartigen Code in jeder Sprache oder in jedem Stil schreiben könnten. Ein Code, mit dem die Zusammenarbeit ein Vergnügen war. Die Quintessenz ist, dass wenn du schlampige Entwickler hast, es egal ist, welchen Stil du verwendest, du wirst schlampigen Code haben.

Aufgrund meiner eigenen persönlichen Benchmarks, ich Opt-out aus Speicher Schwein OOP, vor allem, weil ich wirklich saubere Verfahren schreiben, und ich bin in der Regel der einzige Entwickler auf einem meiner Projekte.

Prost!