Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Hermann Riemann Newsgroups: de.comp.lang.python Subject: =?UTF-8?Q?Re:_[Python-de]_Python_Einf=c3=bchrung_-_Bitte_um_Feedbac?= =?UTF-8?Q?k?= Date: Fri, 10 Mar 2017 11:04:57 +0100 Lines: 32 Message-ID: References: <2831be87-cc5f-2cf2-6999-863f2a021bf4@thomas-guettler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net /JeLpKIvmCdBXBXI34SX3wUkThMdAo0pglzyDz+4C53Aqrpd8k Cancel-Lock: sha1:hIWoY1u5owAYOymRI+LqNxjZTzE= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: Xref: csiph.com de.comp.lang.python:4693 Am 09.03.2017 um 08:53 schrieb Andreas Röhler: > Soweit ich es verstanden habe, bestünde ein eventueller Nachteil in der > möglicherweisen hohen Last, die ein wiederholt aufgerufenes Skript > erzeugen kann Jedes compilierte Programm , dazu gehört auch der interpeter, besteht (nach dem Binden) in Linux aus code, Konstanten und Daten. Beim Ausführen wird code und Konstanten in einem Speicherbereich geladen, und Platz für Daten bereitgestellt. Dieser Platz wird erst dann freigegeben, wenn das RAM "voll" ist. Wenn dass Programm nochmal aufgerufen wird, befinden sich code und Konstanten bereits im Speicher. und werden (nach meiner Vermutung) wiederverwendet. Ebenso die Informationen über den Platz der Daten. ( Kopiere mal 1 TB auf anderen Rechner, dann kannst Du mit top sehen, wie das RAM vollläuft) > - als Grund mutmaße ich die vergleichsweise bescheidene Kompilierung. Vermutlich nur in eine Art pseudocode ( *.pyc dateien.). C artiger code ist einfach nicht effektiv machbar, weil man sonst jede Variable jeden möglichen Typ zuordnen müsste. ( Etwas was vielleicht beim C++ template? Mechanismus den Aufwand in die Höhe treibt. ) Hermann dessen Kenntnisse allerdings etwas alt sind. -- http://www.hermann-riemann.de