[Java] controles vs performance.

[Alarmnummer]

Ik controleer bij methodes altijd even op bv null waardes ed. Maar als iets je iets een stuk sneller wilt maken dan maken die controles je code een stuk langzamer. Je krijgt dus het gevecht tussen controles vs performance.

vb..

code:

public void putIndex(Consequent consequent, int index){ 
   if(consequent == null)            
    throw new NullPointerException("consequent can`t be null");               
   if(index <= -1)           
    throw new IllegalArgumentException("index can`t be smaller than 0");                  
   hashMap.add(consequent,index);    
}

Maar omdat ik zelf deze methodes aanroep weet ik dat het niet voorkomt dat bv consequent null is. Ik weet ook dat ik nooit een index tegenkom kleiner dan 0. Dus ik loop een beetje onnodig te checken.

Wat is jullie visie over dit soort problemen?

ps:misschien kan er ook wel iets worden gedaan met assert commando.

[mbravenboer]

Hier zou ik inderdaad typisch assertions voor gebruiken. Je definieert immers in feite een soort contract waaraan de methode-aanroep moet voldoen. Als je niet aan dat contract voldoet zit je ernstig in de penarie.

[Alarmnummer]

Maar een assert is ook niet gratis. Volgens mij schiet je er niet veel mee op om assert te gebruiken tov RuntimeExceptions. (Je kan geloof ik assert ook uitzetten voor distributie releases). Maar dan kan het voorkomen (in een situatie die jij bij het testen nooit hebt gehad) dat er fouten in voorkomen.

[mbravenboer]

Het punt is inderdaad dat je ze uit kunt zetten, maar ook dat je enigszins onderscheid maakt tussen schending van het contract en 'echte' exceptions. .

Het is inderdaad zo dat er problemen kunnen ontstaan als de assertions uit staan, maar het is juist de bedoeling dat je tijdens de ontwikkelings-fase de assertions gebruikt om je code te controleren. Daarna zouden assertions in principe niet nodig moeten zijn. Als je dit toch wilt controleren zal je ze aan moeten zetten of gewone checks gebruiken...

[Alarmnummer]

Hmmmm... het kan sowieso geen kwaad om runtimeexception om te bouwen naar assert statements. Maar ik ben net een fout tegengekomen waardoor het redeneren nog vrij langzaam gaat.

bv
a=b+b;

hij gaat de 2e b nog een keer berekenen terwijl hij hem wel had moeten vinden. Vandaar dat functies met minder variablen veel sneller evalueren. Ik zal dit eerst eens fixen

[whoami]

Ik zou zeker geen exceptions gaan gebruiken als je er zeker van bent dat die functies enkel door de programmeur worden opgeroepen met ingevulde parameters.

[Verwijderd]

[een beetje off-topic]
Alarmnummer:
Wat ben je voor iets moois aan het proggen? Ik zie de laatste week namelijk allerlei topics langsvliegen over allerlei optimalisaties in Java (en nog veel mooiere monologen ).
Zeer interresant en informatief allemaal, maar nu ben ik toch wel een klein tikkeltje benieuwd wat voor een wereldschokkend snel programmaatje jij aan het ontwerpen bent .
[/een beetje off-topic]

[Alarmnummer]

Op woensdag 23 januari 2002 19:39 schreef KoenM het volgende:
[een beetje off-topic]
Alarmnummer:
Wat ben je voor iets moois aan het proggen? Ik zie de laatste week namelijk allerlei topics langsvliegen over allerlei optimalisaties in Java (en nog veel mooiere monologen ).
Zeer interresant en informatief allemaal, maar nu ben ik toch wel een klein tikkeltje benieuwd wat voor een wereldschokkend snel programmaatje jij aan het ontwerpen bent .
[/een beetje off-topic]

Een dikke rekenmachine

Ben op dit moment (afgelopen 2 jaar) bezig met een expertsysteem. Er komt binnenkort wel meer van op mijn site te staan.

heb ff de site online gezet:
http://129.125.172.114

maar dit is wel erugh oud hoor

[Alarmnummer]

aaaaaarrrrggghhhh... na lang zoeken de fout gevonden.

code:

public boolean equals(Object item){
    _equalsUseCount++;

    if(item == this)
        return true;

    if(item == null)
        return false;

    if(item.hashCode()!=hashCode)
        return false;

    if(!(item instanceof FunctionConsequent))<<STOM
        return false;

    LocalConsequent otherLocalConsequent = (LocalConsequent)item;

    if(otherLocalConsequent.value!=value)
        return false;

    return otherLocalConsequent.identifierList.equals(identifierList);
}

Waar FunctionConsequent staat had LocalConsequent moeten staan, dus de equals die slaagt nooit!! stom stom.

[mbravenboer]

Alarmnummer: Waar FunctionConsequent staat had LocalConsequent moeten staan, dus de equals die slaagt nooit!! stom stom.

Sukkel . Dat zie je toch zo? .

[.oisyn]

Op woensdag 23 januari 2002 20:40 schreef mbravenboer het volgende:

[..]

Sukkel . Dat zie je toch zo? .

ja idd, ik had al zoiets van: zal ik het zeggen? neee dat is zo overduidelijk, dat kan gewoon niet fout zijn

[Alarmnummer]

Alsof jullie nooit iets fout doen

typisch waar je over heen leest

oja.. vergeten.. jullie zijn (schijn) heilig

edit: ojee.. ik loop nu een 2 wannabee mods te stangen

[Alarmnummer]

Er staat een nieuwe screenshot voor de liefhebbers

http://129.125.172.114

[Alarmnummer]

Aha... ik heb het verschil gevonden tussen gebruik assert en RuntimeException. Een AssertException kan je niet afvangen met een try catch en een RuntimeException wel. assert Moet je dus gebruiken als je programmeer fouten tegenkomt.

[Verwijderd]

Sorry als ik iets stom zeg

Wij leren hier op de uni met interfaces te werken, in deze interface beschrijf je de methodes,
//pre: en //post: in pre beschrijf je waar de functie vanuit gaat (bv waarde is niet null en is alphanumeriek).
(post wat er geretourneerd is).
Zou zoiets niet voldoende zijn ?

[Alarmnummer]

Op donderdag 24 januari 2002 10:12 schreef Snow-in-a-can het volgende:
Sorry als ik iets stom zeg

Wij leren hier op de uni met interfaces te werken, in deze interface beschrijf je de methodes,
//pre: en //post: in pre beschrijf je waar de functie vanuit gaat (bv waarde is niet null en is alphanumeriek).
(post wat er geretourneerd is).
Zou zoiets niet voldoende zijn ?

Ik denk dat je het artikel op javaworld even moet doorlezen. Daar zijn voor de taal OAK (voorganger van Java) ook pre en post condition opgesteld Alleen deze taal features zijn er niet ingekomen.

Maar het probleem aan jouw aanpak is dat je niet kan detecteren als er wel iets misgaat (en dat gebeurd er zeker als je of iemand anders software aan het schrijven bent/is) en dan wil ik graag dat ik krijg te zien waar en wat er mis is gegaan.

bv..

code:

public void store(Persoon x, String naam){
   hashmap.put(x,naam)
}

Stel dat je zeker weet dat in jouw systeem x niet null kan zijn maar door een programmeer fout stop je er per ongeluk toch null in. Die zou je niet zo snel detecteren.

maar als je nu

code:

public void store(Persoon x, String naam){
   assert x!=null:"x kan niet null zijn";
   hashmap.put(x,naam);
}

of

code:

public void store(Persoon x, String naam){
   if(x == null)
    throw new NullPointerException("x kan niet null zijn");
   hashmap.put(x,naam);
}

er van maakt dan kun je dit soort fouten er nog wel uitpakken en dus sneller je code debuggen. En die pre conditie van jou is de controle voor de daadwerkelijke uitvoering Ik denk dat je dat artikel wel heel aardig vindt
http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-assert.html

[tomato]

Ik vind het vrij duidelijk dat je voor dit soort dingen assertions gebruikt.
In een interface vinden veel mensen het duidelijk pre en post condities op te nemen als commentaar. Voor iedere pre conditie die daar voor komt gebruik je een assertion. Met assertions vang je dus duidelijk programmeerfouten af.

Exceptions zie ik meer om te gebruiken bij fouten die niet direct aan de programmeur liggen en onverwachter zijn. Bijvoorbeeld bij het schrijven naar een bestand dat daar niet de juiste rechten voor heeft (misschien was dit 1 seconde geleden nog wel het geval, met dit soort dingen kan van alles gebeuren), daar lijken me assertions niet op hun plaats. Ook heeft dit niet direct te maken met de staat waarin de methode aangeroepen moet worden. Daar associeer ik assertions toch mee.

[Alarmnummer]

Voordat assert commando was toegevoegd gebruikte je voor programmeurs fouten de RuntimeException. (Hidden)

Je gebruikt de 'normale' exception voor de 'onverwachte' dingen.

Het voordeel van een assert boven een RuntimeException is dat je een AssertException niet kan catchen. Dus een gebruiker van je api kan nooit zeggen:

code:

setObject(Object item){
   assert item!=null:"item can`t be null";
   this.item = item;
}
....
try{
   jouwObject.setObject(null);
}catch(AssertException e){
   //doe niets omdat ik luie||stomme programmeur ben
}

[mbravenboer]

Hum, ik heb het niet precies bekeken, maar dat kan toch wel?

Het is alleen een AssertionError, wat dus een Error is die je niet zou moeten opvangen...

[Alarmnummer]

Op donderdag 24 januari 2002 14:18 schreef mbravenboer het volgende:
Hum, ik heb het niet precies bekeken, maar dat kan toch wel?

Het is alleen een AssertionError, wat dus een Error is die je niet zou moeten opvangen...

Ik heb het nog een keer zitten doorploegen en het moet inderdaaf geen AssertionException zijn maar een AssertionError. Aangezien (Assertion)Error niet kunt afvangen met

code:

try{
bla..
}catch(RuntimeError e){
   ...
}

wil niet zeggen dat je niet kan afvangen met

code:

try{
   bla
}catch(Error e){
   ...
}

Een assertionError kan je dus wel afvangen met een catch.

An Error is a subclass of Throwable that indicates serious problems that a reasonable application
should not try to catch. Most such errors are abnormal conditions.

Je hebt dus gelijk.

[Alarmnummer]

Maar wat zou je nou hier tegen moet doen?

code:

try{
   bla
}catch(Throwable t){
   //doe niets omdat ik een programmeur ben die zijn geld niet waard is.
}

[tomato]

Ik heb het net ook geprobeerd en kwam er ook achter dat het gewoon kan (java.lang.AssertionError).

In principe gebruik je assertions toch direct aan het begin van je method en wordt er dus gelijk gereturned. Wat dat betreft is het toch eigenlijk helemaal niet zo erg dat ze afgevangen kunnen worden? Blijft wel een feit dat je het nooit zou moeten doen natuurlijk.

[edit]
En volgens mij kun je er dus gewoon niets tegen doen.

[mbravenboer]

Alarmnummer: Maar wat zou je nou hier tegen moet doen?

Tja, waarom zou je er iets tegen willen doen?

Gelukkig is er een scheiding tussen Errors en Exceptions en is het opvangen van Errors erg not-done in normale gevallen. De situatie lijkt mij dus wel duidelijk genoeg eigenlijk?

[Alarmnummer]

Ik heb eerlijk gezegd nog nooit een empty catch gedaan.

code:

try{
   bla
}catch(Exception e){
   //doe niets omdat ik zo gek ben als een deur
}

Maar ik snap eerlijk gezegd 1 van hun argumenten (op javaworld) niet dat de assert beter zou zijn dan de RuntimeException omdat een programmeur die (RuntimeError_ wel eens zou kunnen afvangen met een empty catch. Je kunt een AssertionError ook afvangen, dus in dat opzicht voegt het niets.

Een empty catch bij een runtimeexception is net zo dom als het afvangen (onterecht) van een AssertionError.

[mbravenboer]

Alarmnummer: Een empty catch bij een runtimeexception is net zo dom als het afvangen (onterecht) van een AssertionError.

Idd, maar het vangen een RuntimeException is toegestaan en zelfs aan te bevelen. Het vangen een Error niet .

Het is dus de vraag of het verbreken van een contract iets is wat at runtime opgevangen en zelfs gecorrigeerd mag worden... Daar kan je heel lang over discussieren .

[Alarmnummer]

voor de liefhebbers:
http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html

en als je het uitzet dan worden de checks niet gedaan en heb je niet de kosten ervan.

nog een snelheids tip (stond op javaworld)

code:

static final boolean debug = false;

void bla(){
  .....
  if(debug){
     System.out.prinltn("Allemaal mooie tekst.");
  }
  .....
}

Als je dit doet dan neemt de compiler het if statement niet mee en heb je verder geen kosten onder het draaien van dit soort debug info.

PS: dit gaat alleen op bij static final constanten.

[tomato]

mbravenboer: Idd, maar het vangen een RuntimeException is toegestaan en zelfs aan te bevelen. Het vangen een Error niet .

Precies, ook op dat punt voegen assertions dus zeker wel iets toe.

Het is dus de vraag of het verbreken van een contract iets is wat at runtime opgevangen en zelfs gecorrigeerd mag worden... Daar kan je heel lang over discussieren .

Ik vind van niet. Je misbruikt op die manier de implementatie, terwijl je misschien niet eens weet wat er nu precies in die implementatie gebeurt. Het lijkt me geen veilige manier van programmeren.

[tomato]

Alarmnummer: PS: dit gaat alleen op bij static final constanten.

Uiteraard, dit is natuurlijk een makkelijke optimalisatie voor de compiler

[Alarmnummer]

Op donderdag 24 januari 2002 15:25 schreef tomato het volgende:

[..]

Uiteraard, dit is natuurlijk een makkelijke optimalisatie voor de compiler

Yep maar je kan toch allerlei debuggin info erin zetten die je performance niet hoeft te beinvloeden (als je het uitzet). Geweldig dus

[Alarmnummer]

Hebben jullie misschien nog performance tips?

(geen stringbuffer vs string/ object creatie etc etc) die ken ik allemaal al

[mbravenboer]

Alarmnummer: Hebben jullie misschien nog performance tips?

Object creatie .

[Alarmnummer]

als je een class/method vroeger final maakte dan kon compile time het adres voor de methoden worden bepaald ipv runtime. Dit is natuurlijk veel sneller, en je kreeg dus een performance boost. Maar ik geloof dat dat tegenwoordig niet meer zo is omdat de vm nu kan zien of een methode niet meer overriden wordt. Ik heb hier zelf niet zo snel iets over kunnen vinden op de site van Sun.

[koppie]

Tegenwoordig worden de String-acties in je programma's door de compiler al zoveel mogelijk vervangen door iet met een StringBuffer

[Alarmnummer]

Op donderdag 24 januari 2002 16:03 schreef koppie1 het volgende:
Tegenwoordig worden de String-acties in je programma's door de compiler al zoveel mogelijk vervangen door iet met een StringBuffer

yep

maar dit is nog steeds traag

code:

String s = "":
for(int k=0;k<10;k++){
   s+=""+k;
}

Een enorme hoeveelheid string creaties