[alg/disc] PHP is dood? *

Pagina: 1 2 Laatste
Acties:
  • 219 views sinds 30-01-2008
  • Reageer

Onderwerpen


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
.NET (C#)

page:
HTML:
1
2
3
4
5
6
7
8
9
10
11
12
13
<%@ Page language="c#" Codebehind="Test.aspx.cs" AutoEventWireup="false" Inherits="Bla.Test" %>

<html>
  <head> 
<title>Test</title>
</head> 
<body> 
Starttijd: <asp:label Runat="server" ID="lblStartTijd" /><br>
Eindtijd: <asp:label Runat="server" ID="lblEindTijd" />
<br><br>
Result: <asp:label Runat="server" ID="lblResult" />
</body>
</html>


codebehind:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;

namespace Bla
{
    /// <summary>
    /// Summary description for Test.
    /// </summary>
    public class Test : System.Web.UI.Page
    {
        protected System.Web.UI.WebControls.Label lblStartTijd;
        protected System.Web.UI.WebControls.Label lblResult;
        protected System.Web.UI.WebControls.Label lblEindTijd;
    
        private void Page_Load(object sender, System.EventArgs e)
        {
            DateTime daStartTime, daEndTime;

            daStartTime = DateTime.Now;

            // wat stringetjes maken 
            string test1 = "a test string "; 
            string test2 = " for testing speed"; 
            string test3 = " while operating on strings"; 
            //wat concatineren 
            string test4 = test1+test2+test3; 
            
            //Even naar uppercase/lowecase slechts 5000 keer 
            for( int i=0; i<=10000;i++ )
            { 
                if(i % 2 == 0)
                {
                    test4 = test4.ToUpper();
                }
                else
                {
                    test4 = test4.ToLower();
                }
            } 
        
            daEndTime = DateTime.Now;

            lblStartTijd.Text = daStartTime.ToString("HH-mm-ss-ffff");
            lblEindTijd.Text = daEndTime.ToString("HH-mm-ss-ffff");
            lblResult.Text = test4;
        }

        #region Web Form Designer generated code
        override protected void OnInit(EventArgs e)
        {
            //
            // CODEGEN: This call is required by the ASP.NET Web Form Designer.
            //
            InitializeComponent();
            base.OnInit(e);
        }
        
        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {    
            this.Load += new System.EventHandler(this.Page_Load);

        }
        #endregion
    }
}


Result:
Starttijd: 10-10-45-5937
Eindtijd: 10-10-45-6250

Result: A TEST STRING FOR TESTING SPEED WHILE OPERATING ON STRINGS

Gedraaid in debugmode (dus non-optimized code) meteen na compile, dus geen jit-precache voordeel, op een Dual p3-933 CUS-DLS machine met 512MB ram en win2k server.

edit:
na een aantal keren cntrl-refresh te hebben gedaan zit de jit op 2ms per request :D. Beat that, Sun-boy!

[ Voor 10% gewijzigd door EfBe op 04-02-2003 10:22 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
EfBe: Oh ja jippie. Die gegenereerde docs van Sun. No offence, maar daar heb je geen reet aan.
Ik weet niet of je dit inhoudelijk of qua opzet bedoeld? Als je doelt op de opzet van de gegenereerde docs: er is al een tijde een mechanisme waarmee je vrij gemakkelijk een eigen doc-generator kan inpluggen in Javadoc. Als je dus een ander output formaat wilt, kan je dat zelf maken. Volgens mij is er alleen nog niet echt een subliem idee uitgevoerd, dus wellicht zitten die docs nog niet zo slecht in elkaar ;) .
EfBe: Zegt genoeg over de structuur die erachter zit. In 1995, toen ik mn eerste rotozoomer applet maakte in Java waren arrays al traag en string operaties niet te harden zo langzaam. Als dat in 2003 nog zo is, dan heeft iedere java-programmeur boter op zn hoofd wanneer deze verklaart met state-of-the-art spullen bezig te zijn.
flame doos ;) . Het lijkt mij nogal wiedes dat als je array-bounds checking en immutable strings gebruikt in een platform waarin je ook nog gebruik maakt van een jitter, je performance op dit punt nooit super zal zijn. Als je nu eens geen jitter gebruikt zou je je beperkingen wellicht nog wat kunnen opheffen met compile-time eliminatie van onnodige bounds-checks, maar ja: ga dat at runtime maar eens doen.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Ik doelde op de inhoud van de docs. Of ze moeten heel recentelijk zijn verbeterd, maar wat Sun levert aan docs is ten eerste zeer onoverzichtelijk en ten tweede puur reference materiaal waarbij alleen het alle broodnodige wordt uitgelegd (m.a.w. je hebt er geen reet aan).

Dat arraybounds mee moeten worden gecompileerd snap ik wel, maar dat de JIT daar nu nog steeds zn muil over breekt vind ik toch wel wat raar, aangezien veel mensen arrays gebruiken en je die code best kunt optimizen. String concatenatie is een zeer snelle operatie zeker bij immutable strings, raar dat het dan toch 'traag' is. Naja, het blijft java, dus imho maar voor een aantal mensen echt belangrijk, en off topic ;) (want we waren over php aan het zeuren en niet over Sun's product dat alleen maar geld kost.)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
EfBe: Dat arraybounds mee moeten worden gecompileerd snap ik wel, maar dat de JIT daar nu nog steeds zn muil over breekt vind ik toch wel wat raar, aangezien veel mensen arrays gebruiken en je die code best kunt optimizen.
Uiteraard kan je er veel weg optimaliseren, maar heb je daar at runtime genoeg tijd voor? Het hele model van bytecode die heel dicht bij de oorspronkelijke taal ligt en pas at runtime wordt gecompileerd naar native code werkt gewoon niet als je ingewikkeldere optimalisaties wilt uitvoeren. Een array-bounds check kan je niet uitschakelen in Java bytecode (maar goed ook overigens) en daarom zal het altijd een probleem blijven.
String concatenatie is een zeer snelle operatie zeker bij immutable strings, raar dat het dan toch 'traag' is.
Nou ja, concats zijn in alle talen met immutable data structuren een probleem. Een lijst concat is in functionele talen ook iets wat je wilt vermijden. Zo vreemd is het denk ik niet dat een concat een dure operate is, juist bij immutable data structuren.

Overigens werd er in dit voorbeeld met name de to-upper en to-lower getest en niet zozeer de concat op strings. Als de String ook daadwerkelijk veranderd wordt er steeds een nieuwe String opgebouwd (als hij niet veranderd overigens niet). Dat is dus altijd een trage operatie (hoe bedoel je garbage :O ), wat je ook doet qua optimalisaties.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

EfBe schreef op 04 February 2003 @ 10:16:
Result:
Starttijd: 10-10-45-5937
Eindtijd: 10-10-45-6250
Das toch 31.3 ms?
edit:
na een aantal keren cntrl-refresh te hebben gedaan zit de jit op 2ms per request :D. Beat that, Sun-boy!

2ms om op die p3-933 die code uit te voeren ?
Das wel heel snel, ik had (niet zozeer hiervoor) .oisyn gevraagd of ie een c++ versie wilde maken van de code, op mijn amd athlon xp2100+ doet dat er 17ms over, op zijn athlon 1400 20ms. Een versie die met char-arrays werkt deed er bij hem 8ms over.

Zou jij ons uit kunnen leggen wat .NET allemaal voor optimalisaties weet te doen waardoor dat in 2ms kan op een tragere cpu? :)
Of was het een tikfout, dat is ook mogelijk natuurlijk (20ms ofzo)

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
ACM schreef op 04 februari 2003 @ 23:11:
[nohtml]
[...]

Das toch 31.3 ms?
62-59 = 3 honderste van een seconde, is iid 31.3ms.

[...]
2ms om op die p3-933 die code uit te voeren ?
Das wel heel snel, ik had (niet zozeer hiervoor) .oisyn gevraagd of ie een c++ versie wilde maken van de code, op mijn amd athlon xp2100+ doet dat er 17ms over, op zijn athlon 1400 20ms. Een versie die met char-arrays werkt deed er bij hem 8ms over.
Domme fout van mij. 44-42 == 2 honderste van een seconde, is 20 ms.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

EfBe schreef op 04 February 2003 @ 23:28:
Domme fout van mij. 44-42 == 2 honderste van een seconde, is 20 ms.

Ik vond die tijd al zo knap :)
Het moest ofwel output-cacheing zijn ofwel een foutje. Het eerste zou in het licht van deze "loze" (ja, dat geef ik direct toe ;) ) benchmark niet eerlijk zijn het tweede geeft natuurlijk niet maar is wel handig om te weten :)

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 14:51
mbravenboer schreef op 04 February 2003 @ 12:58:

Nou ja, concats zijn in alle talen met immutable data structuren een probleem. Een lijst concat is in functionele talen ook iets wat je wilt vermijden. Zo vreemd is het denk ik niet dat een concat een dure operate is, juist bij immutable data structuren.

Overigens werd er in dit voorbeeld met name de to-upper en to-lower getest en niet zozeer de concat op strings. Als de String ook daadwerkelijk veranderd wordt er steeds een nieuwe String opgebouwd (als hij niet veranderd overigens niet). Dat is dus altijd een trage operatie (hoe bedoel je garbage :O ), wat je ook doet qua optimalisaties.


Voor die string-concatenatie kon EfBe natuurlijk nog gebruik gemaakt hebben van een StringBuilder in .NET, wat ook nog wat performance winst zou moeten opleveren.
Maar dit is eigenlijk off-topic. :+

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

Verwijderd

whoami schreef op 05 February 2003 @ 09:33:

[...]


Voor die string-concatenatie kon EfBe natuurlijk nog gebruik gemaakt hebben van een StringBuilder in .NET, wat ook nog wat performance winst zou moeten opleveren.
Maar dit is eigenlijk off-topic. :+
Hetzelfde geldt voor Java hoor :) (maar dan heet het StringBuffer :P)

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

whoami schreef op 05 February 2003 @ 09:33:
Voor die string-concatenatie kon EfBe natuurlijk nog gebruik gemaakt hebben van een StringBuilder in .NET, wat ook nog wat performance winst zou moeten opleveren.
Maar dit is eigenlijk off-topic. :+

Als het concateneren van 3 strings aan elkaar zo veel uitmaakt tov dmv een StringBuilder/StringBuffer dat het significant scheelt in bovenstaande testcode voor de executie tijd dan is het eigenlijk wel heel triest gesteld met de performance van de concatenatie ;)

Die concat loopt niet 10000x hoor :P

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 14:51
ACM schreef op 05 februari 2003 @ 12:41:
[nohtml]
[...]
[/nohtml]
Als het concateneren van 3 strings aan elkaar zo veel uitmaakt tov dmv een StringBuilder/StringBuffer dat het significant scheelt in bovenstaande testcode voor de executie tijd dan is het eigenlijk wel heel triest gesteld met de performance van de concatenatie ;)

Die concat loopt niet 10000x hoor :P


Neen, inderdaad, je hebt wel gelijk dat het niet zoveel uitmaakt voor de concatenatie van 3 strings.
Ik wou gewoon nog ff een ander puntje aanhalen. ;)

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • Glimi
  • Registratie: Augustus 2000
  • Niet online

Glimi

Designer Drugs

(overleden)
ACM schreef op 05 februari 2003 @ 12:41:
Als het concateneren van 3 strings aan elkaar zo veel uitmaakt tov dmv een StringBuilder/StringBuffer dat het significant scheelt in bovenstaande testcode voor de executie tijd dan is het eigenlijk wel heel triest gesteld met de performance van de concatenatie ;)

Die concat loopt niet 10000x hoor :P

De concat zal niet echt sneller worden hoor. Dit omdat de overloading van de plus op een String in Java suiker is voor het gebruik van een StringBuffer. Het toUpperCase() toLowerCase() verhaal zal door een stringbuffer het creëren van 10000 objecten-overhead verhaal niet hebben.
Neemt niet weg dat de JITter het huidge geval hoptelijk/waarschijnlijk toch dooroptimaliseerd naar een println( test4.toUpperCase() )

[ Voor 8% gewijzigd door Glimi op 05-02-2003 12:48 ]


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Glimi schreef op 05 februari 2003 @ 12:47:
De concat zal niet echt sneller worden hoor. Dit omdat de overloading van de plus op een String in Java suiker is voor het gebruik van een StringBuffer.
Met zoiets maakt het wel uit natuurlijk
Java:
1
2
3
4
5
6
7
String string = "blaat";
String string2 = "bladiebla";
String string3 = new String();
for(int i = 0; i < 10000; i++)
{
    string3 += string + string2;
}

Als daar stond string3 = string + string2 was het natuurlijk een ander verhaal :)
Omdat dan de overhead precies hetzelfde is als er zelf eerst een stringbuffer tussen zetten.
Het toUpperCase() toLowerCase() verhaal zal door een stringbuffer het creëren van 10000 objecten-overhead verhaal niet hebben.
Neemt niet weg dat de JITter het huidge geval hoptelijk/waarschijnlijk toch dooroptimaliseerd naar een println( test4.toUpperCase() )

Nou... blijkbaar niet.
Ook niet als je de code met java -O compileert ofzo. Dan kost het hier nog zo'n 50ms.

Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
Glimi: Het toUpperCase() toLowerCase() verhaal zal door een stringbuffer het creëren van 10000 objecten-overhead verhaal niet hebben.
Daar zit zeker wel wat in: een toUpperCase en een toLowerCase op een StringBuffer zal veel betere performance laten zien. Helaas zijn alleen bij lange na niet alle String operaties beschikbaar in een StringBuffer en zal je dit dus zelf moeten implementeren.

Probleem daarbij is dan weer dat een toUpperCase en toLowerCase eigenlijk rekening moet houden met de meest bizarre Locales. De code in java.lang.String gebruikt de Character klasse zwaar, maar maakt weer een bijzondere uitzondering van de Turkse Locale. Dit laat denk ik goed zijn dat het design zwak is: een toUpperCase moet je niet implementeren in een String datatype: hij moet kunnen functioneren op alle mogelijk String representaties.
Neemt niet weg dat de JITter het huidge geval hoptelijk/waarschijnlijk toch dooroptimaliseerd naar een println( test4.toUpperCase() )
Zo slim zijn die dingen inderdaad niet. Het is nog maar de vraag of een compile-time compiler (wat een term ;) ) dit wel goed zou kunnen achterhalen zonder ingebouwde kennis te hebben van het gedrag van Strings (en dus gewoon op de Java sources werkt).

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 17-09 19:09

LauPro

Prof Mierenneuke®

Ik ben ook even bezig geweest, ik weet niet of ik het helemaal goed doe maar ik kom op 31,25 ms uit (http://laupro.nl/rommel/test.asp)
ASP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<% Option Explicit

Dim sStartTimer, test1, test2, test3, test4, I

sStartTimer = Timer
    
' wat stringetjes maken  
test1 = "a test string "
test2 = " for testing speed"
test3 = " while operating on strings"
'wat concatineren  
test4 = test1+test2+test3
    
'Even naar uppercase/lowecase slechts ??5000?? 10000 toch .. keer  
For I = 1 To 10000
    If I Mod 2 = 0 Then
        test4 = UCase(test4)
    Else
        test4 = LCase(test4)
    End If
Next

Response.Write Timer - sStartTimer
%>


Ik weet alleen niet wat voor een server het is (maar ik schat zo Pentium 3 1 Ghz oid), bij mij thuis op een Pentium 3 366 Mhz doet hij het 80 ms over.

edit: Ik heb de versie van ACM ook op die server gezet: http://laupro.nl/rommel/test.php

Die doet er 0.462491 seconden over, of tewel ruim 430 ms meer! Voor mij geen php voorlopig :P geintje ;), is btw een wel een IIS server


Misschien leuk dat we een goede test opzetten, want om alleen te mierenneuken op strings scheit niet op. Ik stel voor:
• De bovenstaande code
• Gebruiken van Tan, Cos en Sin (om de rekenkracht met 'Floating Point' e.d. er een beetje uit te halen)
• Gebruik van een database, 10000 keer table createn, 10000 keer records toevoegen, 10000 keer updaten, 10000 keer verwijderen (niet in een keer dus :P), en de 10000 tabellen verwijderen.
• Gebruikt van 'server variabelen' (voor zover die er zijn). Globaal 10000 keer een variabel vullen met een bepaade tekst/waarde.

Dan heb je een iets breder gebied, al deze getalletjes zijn wel mooi maar niet echt gelijkwaardig. Er kunnen natuurlijk meerdere databases worden gebruikt per configuratie.

[ Voor 47% gewijzigd door LauPro op 05-02-2003 21:02 ]

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 17-09 14:05

.oisyn

Moderator Devschuur®

Demotivational Speaker

[nohtml]
LauPro schreef op 05 februari 2003 @ 20:43:
Gebruiken van Tan, Cos en Sin (om de rekenkracht met 'Floating Point' e.d. er een beetje uit te halen)
dit zal bij bijna alle talen op hetzelfde uitkomen. Je zou natuurlijk kunnen kijken hoe goed expressies geoptimaliseerd worden, maar het gebruik van deze functies is totaal nutteloos omdat ze gewoon direct op de CPU werken. Dat is dus meer een processor-benchmark dan een taal-benchmark
Gebruik van een database, 10000 keer table createn, 10000 keer records toevoegen, 10000 keer updaten, 10000 keer verwijderen (niet in een keer dus :P), en de 10000 tabellen verwijderen.
Evenals het vorige voorbeeld is dit meer een database driver benchmark. Je kunt hooguit kijken hoe snel de variabelen worden omgezet zodra ze uit de database zijn gekomen, maar dan heb je er dus ook geen database meer voor nodig aangezien dat gedeelte nou net niet belangrijk is
Gebruikt van 'server variabelen' (voor zover die er zijn). Globaal 10000 keer een variabel vullen met een bepaade tekst/waarde.
ik snap niet helemaal wat je hiermee bedoelt :?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 17-09 19:09

LauPro

Prof Mierenneuke®

.oisyn schreef op 05 February 2003 @ 22:16:
[nohtml]
[...]
dit zal bij bijna alle talen op hetzelfde uitkomen. Je zou natuurlijk kunnen kijken hoe goed expressies geoptimaliseerd worden, maar het gebruik van deze functies is totaal nutteloos omdat ze gewoon direct op de CPU werken. Dat is dus meer een processor-benchmark dan een taal-benchmark.
Hier ben ik het niet helemaal mee eens omdat de meesten bij php als eerste factor de snelheid noemen. Bovendien heb ik van iemand gehoord dat een LAMP-configuratie 70% sneller is dan ASP/IIS. Bovendien kan je kijken welke taal beter geschikt is voor het aanmaken van bijvoorbeeld plaatjes met grafieken e.d. (wat bij sommige talen dus al helemaal niet kan tenzij je plugins gebruikt, maar dan is het weer de vraag tot in hoe ver je bij de taal moet blijven).
[...]
Evenals het vorige voorbeeld is dit meer een database driver benchmark. Je kunt hooguit kijken hoe snel de variabelen worden omgezet zodra ze uit de database zijn gekomen, maar dan heb je er dus ook geen database meer voor nodig aangezien dat gedeelte nou net niet belangrijk is
Nou lijkt mij wel? Stel dat React nu voor ASP/IIS had gekozen, zou het forum dan sneller zijn? Ik vraag me nu wel af of dat php nu werkelijk zoveel scheelt (de kostprijs haal je er uit als het sneller zou zijn).
[...]
ik snap niet helemaal wat je hiermee bedoelt :?
ASP kent bijvoorbeeld Application() en PHP $_GLOBAL[] (meen ik, volgens mij is dit niet helemaal waar wat ik zeg). Dat soort variabelen die 'algemeen zijn', eigenlijk gewoon een dump naar het geheugen toe en weer terug om te kijken hoe de taal er mee omgaat.

[ Voor 3% gewijzigd door LauPro op 05-02-2003 22:25 ]

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 17-09 14:05

.oisyn

Moderator Devschuur®

Demotivational Speaker

LauPro schreef op 05 February 2003 @ 22:24:
[...]
Hier ben ik het niet helemaal mee eens omdat de meesten bij php als eerste factor de snelheid noemen. Bovendien heb ik van iemand gehoord dat een LAMP-configuratie 70% sneller is dan ASP/IIS. Bovendien kan je kijken welke taal beter geschikt is voor het aanmaken van bijvoorbeeld plaatjes met grafieken e.d. (wat bij sommige talen dus al helemaal niet kan tenzij je plugins gebruikt, maar dan is het weer de vraag tot in hoe ver je bij de taal moet blijven).
Nu haal je er echt hele andere functionaliteit bij dan de rekenfuncties zelf. Het zijn gewoon pure functies die, gegeven een argument, een ander getal teruggeven. De taal heeft hier zelf weinig mee te maken als er gewoon gebruik wordt gemaakt van native floating point getallen en FPU functionaliteit. En dat is vrijwel altijd het geval.
Wat jij wil testen is bijvoorbeeld het aanmaken van plaatjes, en dus hoe goed een implementatie is met het accessen van buffers en arrays. Dat je daar trigonometrische functies bij gaat gebruiken is daaraan ondergeschikt
Nou lijkt mij wel? Stel dat React nu voor ASP/IIS had gekozen, zou het forum dan sneller zijn? Ik vraag me nu wel af of dat php nu werkelijk zoveel scheelt (de kostprijs haal je er uit als het sneller zou zijn).
ik had het er net met ele over in #devschuur. Wat je test is een implementatie van een database API die gebruikt wordt in de taal. Zo gebruikt PHP bijvoorbeeld de mysql API die direct op de database werkt, maar ASP zal waarschijnlijk een OLE DB of ODBC API gebruiken. Je test hier de database API, niet de taal. Als je een eerlijke test wilt zul je in alle talen dezelfde onderliggende implementatie moeten gebruiken, anders is het geen eerlijke test.
Wat je zo natuurlijk wel kan testen is welke taal out-of-the-box sneller werkt. Maar goed, wat let je om een snellere implementatie te schrijven en daarvan gebruik te maken in jouw favo taal? Maar als je dat doet kun je niet zeggen dat die taal daarom sneller is
ASP kent bijvoorbeeld Application() en PHP $_GLOBAL[] (meen ik, volgens mij is dit niet helemaal waar wat ik zeg). Dat soort variabelen die 'algemeen zijn', eigenlijk gewoon een dump naar het geheugen toe en weer terug om te kijken hoe de taal er mee omgaat.


Dit zal niet veel anders zijn dan de gewone (locale) variabele die je gebruikt in je scripts/programma's. In oScript worden alle globale variabelen van externe functies gewoon gemapped in de globale context, net als dat je een globale variabele zou declareren in het script. In PHP is het gebruik van $_GLOBAL ook gewoon het gebruik van 'een array', en in ASP waarschijnlijk gewoon het gebruik van een Object.

[ Voor 1% gewijzigd door .oisyn op 06-02-2003 03:32 . Reden: erg foute woordkeuze :) ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 17-09 19:09

LauPro

Prof Mierenneuke®

.oisyn schreef op 05 February 2003 @ 22:37:
[nohtml]
[...]
Nu haal je er echt hele andere functionaliteit bij dan de rekenfuncties zelf. Het zijn gewoon pure functies die, gegeven een argument, een ander getal teruggeven. De taal heeft hier zelf weinig mee te maken als er gewoon gebruik wordt gemaakt van native floating point getallen en FPU functionaliteit. En dat is vrijwel altijd het geval.
Wat jij wil testen is bijvoorbeeld het aanmaken van plaatjes, en dus hoe goed een implementatie is met het accessen van buffers en arrays. Dat je daar trigonometrische functies bij gaat gebruiken is daaraan ondergeschikt
De meeste auto's rijden op benzine, dezelfde benzine, alleen hoe daarmee wordt omgegaan in de auto is verschillend. Je kan niet zeggen dat 1 liter benzine tegenover 15 km staat, dat is per auto verschillend, zo ook met deze talen. Ze zullen welliswaar de 'pure functies' aanroepen, maar dan is het altijd nog wel interesant hoe de taal die functie gebruikt en of er bijvoorbeeld veel vertraging zit in bepaalde checks die vooraf worden uitgevoerd. Dus imo heeft een dergelijke test wel degelijk effect.
[...]
ik had het er net met ele over in #devschuur. Wat je test is een implementatie van een database API die gebruikt wordt in de taal. Zo gebruikt PHP bijvoorbeeld de mysql API die direct op de database werkt, maar ASP zal waarschijnlijk een OLE DB of ODBC API gebruiken. Je test hier de database API, niet de taal. Als je een eerlijke test wilt zul je in alle talen dezelfde onderliggende implementatie moeten gebruiken, anders is het geen eerlijke test.
Wat je zo natuurlijk wel kan testen is welke taal out-of-the-box sneller werkt. Maar goed, wat let je om een snellere implementatie te schrijven en daarvan gebruik te maken in jouw favo taal? Maar als je dat doet kun je niet zeggen dat die taal daarom sneller is
Daar heb je een punt, je meet de taal niet maar de configuratie. Maar over het algemeen is het 'LAMP' tegenover IIS+ASP+Access/MSSQL. En daar lijkt het mij op te gaan, als iemand in php programmeert ga je me niet vertellen dat 'ie nog nooit van MySQL heeft gehoord.
[..]

Dit zal niet veel anders zijn dan de gewone (locale) variabele die je gebruikt in je scripts/programma's. In oScript worden alle globale variabelen van externe functies gewoon gemapped in de globale context, net als dat je een globale variabele zou declareren in het script. In PHP is het gebruik van $_GLOBAL ook gewoon het gebruik van 'een array', en in ASP waarschijnlijk gewoon het gebruik van een Object.
Ook dit is per taal verschillend, niet elke taal zal hetzelfde met variabelen omgaan, een taal heeft een bepaalde beperking qua gebruik van variabelen. Natuurlijk is het onrealistisch om 10k aan variabelen te hebben (en dus niet in een array), maar het is wel handig om te zien wat de effecten zijn en dan vooral ook op de server. Omdat je met zulke grote aantallen werkt zullen de verschillen ook veel duidelijker zijn.

Overigens moet een dergelijke test wel op hetzelfde systeem worden gedaan. Ik ga de test zoals ik hier boven beschreef zelf uitproberen maar dan alleen 'php' tegen 'asp'.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Zo... pff... wat een reacties :)
Sorry voor mijn late reactie, maar ik heb het de laatste tijd erg druk gehad en heb nu weer tijd gehad om alles te lezen en zelf wat te posten.

1e bericht
Als eerste zal ik een reactie geven op m'n post en de reacties hierop. Om te beginnen was de quote aan het begin van m'n bericht misschien niet goed. Het kan op meerdere manieren opgevat worden, maar wat bedoeld wordt is dat je in PHP gewoon fatsoenlijk OO kunt programmeren, zoals in b.v. Java.

Sommige dingen die ik noemde, zoals b.v. parameter meganisme, waren niet negatief over de taal. Het was ook niet de bedoeling om de taal zoveel mogelijk te bekritiseren. Maar meer om mijn mening over de taal op tafel te zetten en jullie over mijn ervaringen ermee te vertellen. (zodat jullie er wat aan hebben)

Met slechte functienamen bedoelde ik de functienamen die PHP aanbiedt. De naamgeving van deze functies vind ik erg slecht.

Voor de duidelijkheid. Ik heb het dus niet over dat PHP OO ondersteunt, maar eigenlijk meer over hoe goed hij deze ondersteunt. Dus of PHP genoeg features ondersteunt. En over wat genoeg is ga ik niet discussieren. Het is naar mijn mening te weinig. >:)

Snel programmeren, Performance :?
Is dat belangrijk? Mijn ervaring in het bedrijfsleven is dat dit helemaal NIETS uitmaakt. Het is nu namelijk veel goedkoper om duurdere hardware te kopen dan software te optimalizeren of een snelle taal te gebruiken. De snelheid moet natuurlijk wel acceptabel blijven, maar of het nu 22 of 20 ms is... dat maakt geen kont uit.

Net als het snel kunnen programmeren van code. Het is absoluut NIET belangrijk dat code snel ingeklopt kan worden, of dat het wat langer duurt. Het moet natuurlijk niet extreem zijn, maar dan zou een taal niet bestaan. Why? Het is algemeen bekend dat bij het ontwikkelen van software 80% van de manuren besteed wordt aan testen en onderhoud van een applicatie en 20% aan het ontwikkelen van de applicatie (Analyse, Ontwerp, Implementatie, enz.). Het is veel handiger om het onderhoud en het testen te versnellen. Het lijkt me dan ook handig dat replys over performance in een nieuwe/andere post komen.

Onderhoud
Onderhoud wordt nog lastiger als je met teams werkt, wat in het bedrijfsleven erg veel voorkomt. Wel eens een bug in de software van een oudcollega mogen oplossen? Onderhoud is dus belangrijk, maar hoe kun je de tijd die hiervoor gebruikt wordt verkorten?

Debuggen, dit heb ik in m'n 1e bericht ook al genoemd en herhaal ik voor de duidelijkheid maar even.

Private variabelen. Dit heb ik in m'n 1e bericht ook gepost, maar er zijn reacties hierop gekomen. De programmeur zou zich er maar gewoon netjes aan moeten houden. Dit is makkelijker gezegd dan gedaan, vooral als je in teamverband werkt. Programmeurs hebben vaak de neiging om snel iets uit te programmeren. Het rechtstreeks aanroepen van instance variabelen komt hier erg handig van pas :)

Zo heb je ook nog: Interfaces, Strong typing, Systeem documentatie, enz... Maar daar hebben we er al genoeg van gehoord. Naar mijn mening is PHP geen onderhoudsvriendelijke taal en gaat in het onderhouden van software veel meer tijd zitten dan in sommige andere talen.

Waarom is PHP dan populair?
Daar heb ik een vrij simpel antwoord op. "Het is simpel" Dit heeft het voordeel dat het implementeren veel sneller gaat, maar het onderhouden dus veel langer duurt. Een aantal berichten terug las ik het advies, dat je een taal moet gebruiken, die geschikt is voor waar je mee bezig bent. PHP lijkt me dan een erg goede taal voor "throwaway prototyping" en zoals gezegd voor kleine projecten.

Acties:
  • 0 Henk 'm!

  • djc
  • Registratie: December 2001
  • Laatst online: 08-09 23:18

djc

Verwijderd schreef op 06 februari 2003 @ 20:26:
Met slechte functienamen bedoelde ik de functienamen die PHP aanbiedt. De naamgeving van deze functies vind ik erg slecht.

Voor de duidelijkheid. Ik heb het dus niet over dat PHP OO ondersteunt, maar eigenlijk meer over hoe goed hij deze ondersteunt. Dus of PHP genoeg features ondersteunt. En over wat genoeg is ga ik niet discussieren. Het is naar mijn mening te weinig. >:)
Met het eerste punt ben ik het eens, maar er is weinig enthousiasme om er iets aan te doen, omdat iedereen er al gewend aan is. Jammer, maar helaas. Wat je tweede punt betreft, daar ben ik het mee eens, en voor PHP 5 (geschat stable in augustus 2003) zijn er grote uitbreidingen op dit punt. Dingen als public, protected en private komen er dan in, objecten worden standaard als reference doorgegeven, en meer van die dingen. Daar komt dus verbetering in.
Verwijderd schreef op 06 februari 2003 @ 20:26:
Net als het snel kunnen programmeren van code. Het is absoluut NIET belangrijk dat code snel ingeklopt kan worden, of dat het wat langer duurt. Het moet natuurlijk niet extreem zijn, maar dan zou een taal niet bestaan. Why? Het is algemeen bekend dat bij het ontwikkelen van software 80% van de manuren besteed wordt aan testen en onderhoud van een applicatie en 20% aan het ontwikkelen van de applicatie (Analyse, Ontwerp, Implementatie, enz.). Het is veel handiger om het onderhoud en het testen te versnellen. Het lijkt me dan ook handig dat replys over performance in een nieuwe/andere post komen.
Dat is nu juist het punt. PHP wordt (meestal) niet gebruikt voor dat soort software. Er zijn uitzonderingen (zoals React), maar daarbij wordt zorgvuldig gepland, een uitgebreid framework bedacht, enzovoort. De meeste gebruikers ontwikkelen in PHP meer een beetje zoals shell scripting voor het web. Het is gewoon een krachtig (hoewel enigszins beperkt, misschien) taaltje om van die kleine dingetjes mee te doen, wat simpele queries in een DB te gooien, wat klooien met XML, dat soort dingen. Daar is PHP voor. En daar is het *zeer* geschikt voor.
Verwijderd schreef op 06 februari 2003 @ 20:26:
Zo heb je ook nog: Interfaces, Strong typing, Systeem documentatie, enz... Maar daar hebben we er al genoeg van gehoord. Naar mijn mening is PHP geen onderhoudsvriendelijke taal en gaat in het onderhouden van software veel meer tijd zitten dan in sommige andere talen.
Ik denk dat dat een van de voornaamste minpunten van PHP is: het is inderdaad *erg* onderhoudsonvriendelijk. Het enige wat je daaraan kunt doen is een framework maken met extra functionaliteit, en duidelijke afspraken maken met collega-devvers.
Verwijderd schreef op 06 februari 2003 @ 20:26:
Daar heb ik een vrij simpel antwoord op. "Het is simpel" Dit heeft het voordeel dat het implementeren veel sneller gaat, maar het onderhouden dus veel langer duurt. Een aantal berichten terug las ik het advies, dat je een taal moet gebruiken, die geschikt is voor waar je mee bezig bent. PHP lijkt me dan een erg goede taal voor "throwaway prototyping" en zoals gezegd voor kleine projecten.
Precies. Alleen is de drempel naar (bijvoorbeeld) JSP/Java nog best groot, ook omdat het maar bij weinig hosting-providers is geinstalleerd. Dan zit je dus ineens in een heel ander segment. Daarom wordt PHP iets te veel gebruikt voor wat grotere projecten, waar iets als Java misschien wel geschikter zou zijn.

Rustacean

Pagina: 1 2 Laatste