php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 16-10-2006, 17:28
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard Performance beim Einbinden von Templates

Hallöchen, mal ne Frage:

Ich habe strikt Design von Programmierung getrennt und verwende Platzhalter in meinen Templates a la {_PLATZHALTER_}.

Nun habe ich auf manchen Seiten Platzhalter, die nur gelegentlich auf Seiten vorkommen, z.B. lass ich in Formularen die Session-ID in ein Hiddenfield schreiben. Da dies ja nicht auf allen Seiten der Fall ist und nur sehr selten bei Formularen benötigt wird, ist meine Frage, ob es Sinn macht vorher mit if(eregi("{_XXX_}", $page)) zu prüfen, ob es diesen Platzhalter gibt und dann per preg_replace() zu ersetzen oder ob ich immer gleich preg_replace() einsetzen kann, egal ob was gefunden wird oder nicht.

Also um es kurz zu machen: ist eregi() beim reinen Auffinden schneller als preg_replace()? Oder sollte ich sogar preg_match() benutzen?

Es geht mir darum, auf den meisten Seiten einfach nicht mehrfach den ganzen Content nach Platzhaltern zu filtern, die eh nur auf ein paar Seiten benutzt werden.

Dank & Grüße,
Andi
Mit Zitat antworten
  #2 (permalink)  
Alt 16-10-2006, 17:36
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard Re: Performance beim Einbinden von Templates

Was macht preg_replace? 1. Suchen, 2. Ersetzen

Jetzt möchtest du also wissen, ob erst mal prophylaktisch Suchen, und dann noch einmal Suchen und anschließend Ersetzen schneller wäre ...?
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #3 (permalink)  
Alt 16-10-2006, 17:49
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

JA, genau, weil bei 97 % der Seiten Suchen und nix finden der Fall sein wird und nur bei dreien auch dann tatsächlich was ersetzt werden soll. Also bei den drei Prozent ist mir dann das doppelt Suchen egal, wenn sich bei den anderen Seiten dadurch etwas an Performance sparen lässt.
Mit Zitat antworten
  #4 (permalink)  
Alt 16-10-2006, 17:53
Wurzel
 Master
Links : Onlinestatus : Wurzel ist offline
Registriert seit: Jul 2002
Ort: double-u-upper-valley
Beiträge: 7.477
Wurzel ist zur Zeit noch ein unbeschriebenes Blatt
Standard

tausche in dem fall eregi gegen preg_match, wenn du wirklich einen regulären ausdruck benutzt. ansonsten dürfte ein strstr() oder stristr() schneller laufen.
__________________
Kissolino.com
Mit Zitat antworten
  #5 (permalink)  
Alt 16-10-2006, 18:00
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Original geschrieben von andik2000
wenn sich bei den anderen Seiten dadurch etwas an Performance sparen lässt.
Was soll sich denn da sparen lassen?

Noch mal:
Zitat:
Original geschrieben von wahsaga
Was macht preg_replace? 1. Suchen, 2. Ersetzen
Wie viel Rechenzeit wird deiner Meinung nach preg_replace wohl mit dem Ersetzen verschwenden, wenn es zuvor beim Suchen nichts gefunden hat?


Du möchtest, wo du gerade schon mal an der Tanke stehst, den Ölstand deines Wagens kontrollieren und ggf. auffüllen.
Dazu müsstest du erst mal den Ölstand kontrollieren, und wenn er zu niedrig ist, Öl nachfüllen. Da du leider nur eine dumme PHP-Funktion bist, kannst du nur nachfüllen, nach dem du vorher höchstselbst den Ölstand selbst kontrolliert hast - du bist darauf programmiert, etwas anderes kannst du nicht, bzw. dir fehlt das Vertrauen, wenn dir jemand anderes vorher sagt, "ja, Ölstand ist zu niedrig, muss nachgefüllt werden."
Trotzdem willst du jetzt deinen Beifahrer zuerst aussteigen lassen, damit er den Ölstand kontrolliert. Sagt er, "alles OK, ist noch voll" - dann fahrt ihr weiter. Da hätte es genauso lange gedauert, als wenn du selber nachgeschaut hättest, und nicht nachgefüllt hättest.
Sagt er aber, "nee, da muss noch was rein" - dann steigst du also aus, misst selber erst mal nach - merkst "hey, richtig, da muss ja wirklich nachgefüllt werden", und füllst nach.
Kannst du mir erzählen, wo ihr jetzt Zeit gespart habt ...?
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #6 (permalink)  
Alt 16-10-2006, 18:02
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Original geschrieben von Wurzel
tausche in dem fall eregi gegen preg_match, wenn du wirklich einen regulären ausdruck benutzt. ansonsten dürfte ein strstr() oder stristr() schneller laufen.
Wenn es eh nur fixe Textliterale sind, ersetzt werden sollen - dann kann er auch gleich str_replace verwenden.
Ob er da auch auf die Idee käme, erst mal strpos o.ä. vorzuschalten ...?
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #7 (permalink)  
Alt 16-10-2006, 18:45
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

@ Wahsaga: Nach meinen Erfahrungen ist preg_replace wesentlich schneller im Vergleich zu ereg_replace. Auch str_replace ist langsamer.

Darum ist meine Überlegung, dass vielleicht eine reine Funktion zum Suchen eines Strings schneller arbeitet als eine zum Suchen und Ersetzen. So wie ja auch preg schneller läuft als ereg, weil einfach ein anderes Verfahren benutzt wird.

Und um bei Deinem Beispiel zu bleiben, ist mein Beifahrer vielleicht nicht angeschnallt und jünger und kann daher vielleicht schneller aufspringen um nach dem Öl zu schauen als ich. Und darum lass ich ihn dann lieber an jeder Ampel schnell mal nach dem Öl schauen, bevor ich mich auf den Weg mache und erst aus dem Kofferraum das Öl hole, denn es könnte ja sein, dass ich was nachfüllen muss - und wenn nicht, dann lauf ich erst wieder zum Kofferraum das Öl wegpacken, bevor ich weiterfahre.

Und wie gerne würde ich an dieser Stelle mal wieder Dieter Nuhr zitieren


@ Wurzel: yo danke, denke auch, dass preg_match schneller laufen wird. strstr() werde ich mal checken. Wobei ich den Eindruck habe, dass die PCRE-Funktionen auch bei keinem komplexen RegExp wesentlich schneller matchen als die übrigen String-Funktionen.

Ich dachte es hat vielleicht jemand konkrete Fakten, dass Funktion X schneller arbeitet als Funktion Y.
Mit Zitat antworten
  #8 (permalink)  
Alt 16-10-2006, 19:10
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

OffTopic:
Noch mal zum lieben wahsaga:

Meine Frage war nach der konkreten Ausführungszeit zweier unterschiedlicher Funktionen. Die eine sucht nur, die andere sucht und ersetzt.

Was Du daraus machst ist folgendes:
Ich frage Dich, ob ein Porsche schneller ist als ein VW Käfer. Deine Antwort demnach ist: Beides Autos, ist doch egal. Wenn Stau ist, bist Du mit dem Käfer genau so schnell am Ziel wie mit dem Porsche. Man könnte aber auch den Porschemotor in den Käfer einbauen, dann wäre der genau so schnell. Wieso willst Du überhaupt mit dem Porsche fahren, der Käfer ist doch viel schöner. Oder so was in der Art.

Meine Frage hat das allerdings nicht beantwortet und nur mal wieder Zeit und Nerven gekostet.

Du vermutest also, dass sich die beiden Funktionen in ihrer Ausführungszeit gleich verhalten. Wieso schreibst Du das dann nicht einfach. Wirklich wissen tust Du es allerdings nicht. Also alles Spekulation. Genau wie ich spekuliere, dass eine reine Suche schneller abläuft als eine Suche mit Ersetzen, auch wenn letzteres nicht zum Einsatz kommt. Wissen tue ich es allerding nicht genau, darum frage ich. Kann ja sein, dass sich hier einer tiefer in den internen Abläufen des PHP-Parsers auskennt.

Aber jetzt weis ich auch, wer mir demnächst mal den Ölstand messen darf

Grüße, Andi

Mit Zitat antworten
  #9 (permalink)  
Alt 16-10-2006, 19:57
3DMax
 PHP Senior
Links : Onlinestatus : 3DMax ist offline
Registriert seit: Jan 2004
Beiträge: 1.916
3DMax ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Original geschrieben von andik2000
@ Wahsaga: Nach meinen Erfahrungen ist preg_replace wesentlich schneller im Vergleich zu ereg_replace. Auch str_replace ist langsamer.
str_replace ist ja nun mal bekanntermaßen das schnellste verfahren, siehe auch hier:
PHP-Benchmarks

Zitat:
Original geschrieben von andik2000
Darum ist meine Überlegung, dass vielleicht eine reine Funktion zum Suchen eines Strings schneller arbeitet als eine zum Suchen und Ersetzen. So wie ja auch preg schneller läuft als ereg, weil einfach ein anderes Verfahren benutzt wird.
und ich vermute auch, dass grundsätzlich suchen/ersetzen schneller ist, als suchen - suchen/ersetzen (irgendwie logisch).
bei o.g. benchmark hätte ich aber auch vermutet, dass str_replace mit arrays schneller ist, als einzelne str_replace ohne array.

aber wie wärs denn, du schreibst deinen eigenen benchmark und präsentierst hier das ergebnis? - wäre eventuell sinnvoller, als hier komische autovergleiche anzustellen.
Mit Zitat antworten
  #10 (permalink)  
Alt 16-10-2006, 20:01
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Original geschrieben von andik2000
Ich frage Dich, ob ein Porsche schneller ist als ein VW Käfer. Deine Antwort demnach ist: Beides Autos, ist doch egal.
Nein, das war nicht meine Antwort.

Wenn du meine Antworten nicht verstehst, könntest du dann die Klappe bitte nicht so groß aufreissen? Danke.

Zitat:
Nach meinen Erfahrungen ist preg_replace wesentlich schneller im Vergleich zu ereg_replace.
Und deshalb schriebst du eingangs, Zitat, zur Erinnerung:
Zitat:
ist eregi() beim reinen Auffinden schneller als preg_replace()?
Deiner Erfahrung nach (die du selbst noch in Frage stellst), willst du also lieber erst mal das langsamere zum Suchen nehmem? Widerspruch, oder?

Zitat:
Auch str_replace ist langsamer.
Würde ich für konstante Suchausdrücke bestreiten wollen.
Zitat:
Meine Frage hat das allerdings nicht beantwortet und nur mal wieder Zeit und Nerven gekostet.
Och du armer - musst du jetzt psychologisch betreut werden?
Zitat:
Du vermutest also, dass sich die beiden Funktionen in ihrer Ausführungszeit gleich verhalten. Wieso schreibst Du das dann nicht einfach.
Ich halte den ganzen Ansatz für unsinnig - und das schrieb ich wohl auch.
Zitat:
Wirklich wissen tust Du es allerdings nicht. Also alles Spekulation. Genau wie ich spekuliere, dass eine reine Suche schneller abläuft als eine Suche mit Ersetzen, auch wenn letzteres nicht zum Einsatz kommt. Wissen tue ich es allerding nicht genau, darum frage ich.
Mit solchen Fragen befasse ich mich normalerweise nicht intensiver - weil es die Erfahrung zeigt, dass die Leute, die immer wieder wegen solcher "Optimierungen" fragen meistens die sind, die noch genügend andere Böcke in ihren Scripten schießen, die weit unperformanter sind.

Ja, ich halte das für eine Newbee-Frage - die kommen regelmäßig mit sowas an, ohne sich erst mal Gedanken zu machen, welche Stellen zur Optimierung vielleicht sinnvoller wären.

Von jemandem mit halbwegs Ahnung würde ich erwarten, dass er
a) im Zweifelsfalle erst mal ermittelt, welche Stellen des Systems zu unperformant sind, und dann gezielt nach Optimierungsmöglichkeiten sucht. Dass du hier wirklich gezielt nachgemessen und eine Engstelle ausgemacht hast, bezweifle ich aber; und
b) beim Auftauchen so einer Frage in der Theorie einen test case/benchmark aufbaut, und eigene Messungen damit vornimmt.


Vom Dieter Nuhr darfst du dich m.E. gerne adressiert fühlen.
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #11 (permalink)  
Alt 16-10-2006, 22:09
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Also Leute, da kann ich mir echt nur an den Kopf fassen. Red ich denn wirklich chinesisch oder bin ich der Einzige der hier einen logischen Denkansatz versucht?

Naürlich habe ich Wahsagas Argumentation verstanden, aber er wohl nicht meine Frage. Die da noch mal genau wäre:

Ist es möglich, dass eine Funktion, die nur auf das Vorhandensein einer Zeichenkette prüft schneller arbeitet als eine die sucht und auch ersetzen will?

Da es da ja verschiedenen Methoden zum Suchen und Suchen + Ersetzen gibt, hätte ich nur gerne gewusst, ob es einen Sinn machen würde, eine dieser Funktionen zu bevorzugen. Dass es dann bei machen Seiten zu einer doppelten Suche kommt, ist mir auch klar. Nur gib es davon ganz wenige.

Und bitte, der Vergleich von Wahsaga sagt mir nur, dass ich im Falle eines Treffers zwei mal suche um ein mal zu ersetzen. Auf 97% der Seiten wird jedoch nur einmal gesucht und garantiert nichts gefunden. Wenn man das durch einen schnelleren Suchalgorhythmus optimieren kann, wäre das doch super.

Da will ich auch selbst keine Benchmarks fahren, ich verfahre bislang sowieso nur nach suchen + ersetzen. Es war ja nur eine Überlegung ob es anders nicht performanter wäre, weil irgendwo logisch. Hätte sein können, dass jemand hier schon seine Erfahrungen damit gemacht hat.

Und um Stellung zu nehmen:

Zitat:
Zitat:
ist eregi() beim reinen Auffinden schneller als preg_replace()?
Deiner Erfahrung nach (die du selbst noch in Frage stellst), willst du also lieber erst mal das langsamere zum Suchen nehmem? Widerspruch, oder?
Wenn Du genau liest, habe ich auch preg_match() vorgeschlagen. Warum kommt dann keine Erklärung, dass X schneller ist als Y oder besser aus dem und dem Grund oder es sich gleich bleibt. Stattdessen lässt man hier den Klugscheisser raushängen, gibt seinen Senf dazu und hat die Grundidee hinter der Frage noch nicht mal verstanden - oder sich zumindest so geschickt ausgedrückt, dass es für den Fragesteller so den Eindruck macht.

Aber wahsaga, so ne Diskussion hatten wir schon mal. Es sind nicht alles Deppen hier, die Fragen stellen. Und wenn Du keinen Bock auf Newbees hast (was ich wohl nach 5 Jahren nicht mehr sein dürfte), dann beteilige dich doch nur an hochprofessionellen Treads und gib dann lieber mal keinen Kommentar ab.

Alles was ich wollte, war eine Aussage wie sie von Wurzel kam. Danke, geht doch.

Ihr arbeitet doch auch sicher nach ähnlichem Prinzip mit Platzhaltern. Wie ersetzt ihr die? Warum sagt nicht mal einer: "Ich mach das so und so weil..." Benutzt man besser str_replace, preg_replace, ereg_replace...?
Ein Beispiel wie meine Platzhalter im HTML-Layout aussehen "{_PLATZHALTER_}" habe ich ja auch gegeben.

Wie ich schon sagte, arbeitet meiner Erfahrung nach preg_replace am schnellsten. Vor längerer Zeit hatte ich bei einem CMS den Content nach bestimmten TAGs filtern lassen. Ich habe keinen serverseitigen Benchmark laufen lassen, sondern das Resultat lag zwischen Absenden und Sehen der Seite im Browser zwischen teilweise 5 Sekunden mit str_replace und einer sofortigen Anzeige mit preg_replace.
Getestet an verschiedenen Tagen, mehrfach hintereinander, auf zwei unterschiedlichen Servern. So habe ich mir mein Urteil drüber gibildet. Studierte Informatiker mögen anders drüber denken, aber dann teilt mir bitte sachlich eure Meinung und Begründung mit, aber kommt nicht mit so einer nichtssagenden Ölschmiere daher.

Ist schon klar, dass zwei mal suchen und einmal ersetzen keinen Sinn macht. Es ist nur Theorie!!! Wenn man davon ausgeht, dass es MEISTENS NICHTS zu finden gibt: Würde das doch MÖGLICHERWEISE eine reine Suche schneller herausfinden, als eine Funktion die eigentlich suchen und ersetzen will? Weil sie vielleicht einen anderen Suchalgorhythmus benutzt oder der Code zu dieser Funktion einfach viel kürzer ist, weil sie ja nur eine Aufgabe erfüllen muss.
Denn wir wissen ja sogar, dass Funktionen, die Augenscheinlich das gleiche machen, unterschiedlich schnell arbeiten.

Kann meinen Gedankengang irgendwer logisch nachvollziehen?

Wenn aber keiner einen Benchmark gemacht hat oder genau weis wie der Parser solche Anfragen verarbeitet oder anderweitige aussagekräftige Erfahrungen in diesem Zusammenhang gemacht hat, dann macht es auch keinen Sinn darauf zu antworten.

So ich fahr jetzt Heim! Wann muss ich eigentlich wieder zum Ölwechsel?
Mit Zitat antworten
  #12 (permalink)  
Alt 16-10-2006, 22:29
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Original geschrieben von andik2000
Red ich denn wirklich chinesisch oder bin ich der Einzige der hier einen logischen Denkansatz versucht?
Du bist der einzige Chinese, der hier einen sinnfreien Denkansatz verfolgen will ...

Zitat:
Ist es möglich, dass eine Funktion, die nur auf das Vorhandensein einer Zeichenkette prüft schneller arbeitet als eine die sucht und auch ersetzen will?
Wenn das im Bereich des Möglichen läge - würde dann nicht die Funktion, die Suchen&Ersetzen als Aufgabe hat, vermutlich den gleichen Algorithmus nutzen wie die, die nur Suchen will?
Zitat:
Da es da ja verschiedenen Methoden zum Suchen und Suchen + Ersetzen gibt, hätte ich nur gerne gewusst, ob es einen Sinn machen würde, eine dieser Funktionen zu bevorzugen.
Dass die preg-Funktionen im Allgemeinen als wesentlich performanter gelten, als ihre ereg-"Gegenstücke", haben wir ja nun zur Genüge festgestellt - und eigentlich war's auch vorher schon herausfindbar.

Zitat:
Da will ich auch selbst keine Benchmarks fahren
Du willst also selbst keine Arbeit in die Beantwortung der Frage stecken - erwartest das aber von anderen, die den Ansatz unter Angabe von Begründung schon von vorhererein für ziemlich sinnfrei halten?
Zitat:
Warum kommt dann keine Erklärung, dass X schneller ist als Y oder besser aus dem und dem Grund oder es sich gleich bleibt.
Weil schon im Manual erwähnt steht, dass preg idR. die schnellere Alternative darstellt ...?

Zitat:
Stattdessen lässt man hier den Klugscheisser raushängen, gibt seinen Senf dazu und hat die Grundidee hinter der Frage noch nicht mal verstanden -
Natürlich wurde die verstanden - und stante pede abgelehnt, weil als extrem unsinnig erachtet.

Zitat:
Ist schon klar, dass zwei mal suchen und einmal ersetzen keinen Sinn macht.
Aha - Einsicht?
Zitat:
Es ist nur Theorie!!!
Fein - und morgen thematisieren wir dann alchemistische Fragen, wie zum Beispiel woraus sich am besten Gold herstellen lässt ... bleiben Sie dran!
Zitat:
Wenn man davon ausgeht, dass es MEISTENS NICHTS zu finden gibt: Würde das doch MÖGLICHERWEISE eine reine Suche schneller herausfinden, als eine Funktion die eigentlich suchen und ersetzen will?
Weil eine IF-Verzweigung in einem compilierten Sprachinterpreter so hochgradig unperformant sein müsste ...?
Zitat:
Weil sie vielleicht einen anderen Suchalgorhythmus benutzt
Nochmal: Warum sollte sie?
Warum sollte man für eine Funktion, die "nur Suchen" soll, einen unperformanteren Algorithmus implementieren als für die, die anschließend auch noch ersetzen soll?
Schon auf den Gedanken gekommen, dass die Vermeidung von Parallelentwicklung wesentlicher Bestandteil sinnvoller Programmierung ist - und u.a. dafür das Konstrukt der "Funktionen" entwickelt wurde?

Zitat:
oder der Code zu dieser Funktion einfach viel kürzer ist, weil sie ja nur eine Aufgabe erfüllen muss.
Du nimmst nicht wirklich an, dass die Zeitdauer der Abarbeitung einer Funktion, die in verschiedene Zweige springen kann, von ihrer Gesamtlänge abhängt?
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #13 (permalink)  
Alt 17-10-2006, 02:15
3DMax
 PHP Senior
Links : Onlinestatus : 3DMax ist offline
Registriert seit: Jan 2004
Beiträge: 1.916
3DMax ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Original geschrieben von wahsaga
Du willst also selbst keine Arbeit in die Beantwortung der Frage stecken - erwartest das aber von anderen, die den Ansatz unter Angabe von Begründung schon von vorhererein für ziemlich sinnfrei halten?
@whasaga du hast es damit auf den punkt gebracht.

OffTopic:
in der heutigen pisa-gesellschaft ist geiz zwar geil, aber leider beziehen das manche bild-zeitungs-leser (andik2000) auch auf eigeninitiative und hirn
Mit Zitat antworten
  #14 (permalink)  
Alt 17-10-2006, 15:03
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Also mir ist das alles zu blöd. Sorry, ich bin halt nicht der mega Informatik-Freak. Ich hatte eine Idee und wollte eine konkrete Antwort ob sinnvoll oder nicht.

Der Öl-Vergleich von Wahsaga gab mir keine Information drüber, ob beide Funktionen tatsächlich gleich schnell arbeiten sondern nur, dass beide bis aufs Ersetzen zunächst das gleiche machen. Das war mir schon klar - danke.

Einzig die letzte Aussage eben:
Zitat:
Du nimmst nicht wirklich an, dass die Zeitdauer der Abarbeitung einer Funktion, die in verschiedene Zweige springen kann, von ihrer Gesamtlänge abhängt?
...sagt mir nun endlich irgendwie, dass wohl beide Funktionen gleich schnell arbeiten werden. Danke. Tut mir leid, dass ich ausser PHP nix kenne und nicht weis wie so ein kompiliertes Programm arbeitet. Habt Nachsicht.

Vergesst einfach die letzten Threads. Haben wir wohl etwas aneinander vorbei geredet. Aber schön, dass ihr so toll auf einem rumhacken könnt, anstatt mal Tacheles zu reden.

Hab jetzt auch keinen Bock weiter darüber zu philosophieren.
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 10:01 Uhr.