Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 13
  1. #1

    Problema differenza velocità file jar e lanciato da IDE

    Scusate per il titolo ma non avevo proprio idea di cosa scrivere. Ho creato un programma che scarica da internet un pagina web ed esegue alcune operazioni su di essa, se lancio il main da bluej e premo poi il bottone per fare partire l'operazione il tutto si conclude in circa 20 secondi (la dimensione della pagina è circa 180 kb) mentre se eseguo il file jar oppure l'exe (creato con exe4j ) ci mette circa 1 minuto e 20! Il problema è nello scaricamento della pagina, alla pressione del bottone parte un altro thread che se ne occupa che esegue lo scaricamento, la filtrazione dei risultati, l'aggiornamento della jprogress bar e della jlist (in cui compaiono i risultati). La cosa ancora più strana è che ho aggiunto un system.out.println al metodo che scarica il sorgente da internet che mi stampa cosa sto scaricando mano a mano, e se eseguo il file jar via cmd (con java .jar nomefile.jar) funziona normalmente! Cioè ci mette circa 20-30 secondi a finire tutto Può essere che dipenda dal server e non dall'applicazione? Anzi ora sono riuscito a vedere cosa succede, a volte lo scaricamento del sorgente si interrompe e poi riprende, ma da bluej questo non succede...
    Mistero Misteriossso!

    codice:
    String source="";         
    try{            
       int count;
       URL url = new URL( address); 
       HttpURLConnection httpcon = (HttpURLConnection) url.openConnection();
       httpcon.addRequestProperty("User-Agent", "Mozilla/5.0");
       BufferedReader inStream = new BufferedReader(new InputStreamReader(httpcon.getInputStream())); 
      Scanner in=new Scanner(inStream);
      while(in.hasNext())
     { 
          String temp=in.next();
           source+=temp+" ";
           new errore(temp);} 
           source=source.replaceAll(".","."); 
              source=source.replaceAll(":",":"); 
                source=source.replaceAll("’","'"); 
                source=source.replaceAll("…","...");  
               source=source.replaceAll("–","-");      
           source=source.replaceAll("&","&");  
    }  catch(MalformedURLException ex)         { 
         new errore("Html : "+ex.getMessage());  } 
         catch(IOException ex)        
     {      new errore("Html : "+ex.getMessage());         }
         return source;     }

  2. #2
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    Codice PHP:
            String source="";         
            try{            
               
    int count;
               
    URL url = new URLaddress); 
               
    HttpURLConnection httpcon = (HttpURLConnectionurl.openConnection();
               
    httpcon.addRequestProperty("User-Agent""Mozilla/5.0");
               
    BufferedReader inStream = new BufferedReader(new InputStreamReader(httpcon.getInputStream())); 
              
    Scanner in=new Scanner(inStream);
              
    StringBuffer buff = new StringBuffer(""); 
              while(
    in.hasNext()){ 
                   
    buff.append(in.next());
                   
    buff.append(" "); 
              }
              
              
    source buff.toString(); 
                
    System.out.println(source);
            } catch(
    MalformedURLException ex){ 
            
    // m entre sviluppi meglio 
                
    ex.printStackTrace(); 
                 
    //new errore("Html : "+ex.getMessage());  
             
    }catch(IOException ex){
                   new 
    errore("Html : "+ex.getMessage());         
             }
             
             return 
    source
    questo dovrebbe farti guadagnare tempo (dentro i cicli è preferibile non fare append a string con "+").

    poi perché fai quelle replace? problemi di codepage?

    in realtà penso che il tuo eseguibile tiri su una virtual machine, per questo impiega un po' di tempo
    RTFM Read That F*** Manual!!!

  3. #3
    La velocità è quasi raddoppiata!!! è sempre bello imparare cose nuove i replace sono necessari perchè uso le regex e il sito in questione rimpiazza spesso i caratteri, è più facile cercare un "." piuttosto che un "." (non so bene cosa sia il codepage eeeee grazie wikipedia: UTF-8) potrei modificare le regex ma dovrei comunque fare un replace dopo (sennò nella jlist mi comparirebbero ad esempio ":" al posto di ":" )
    Adesso provo dal file jar.. E' SCESO A 4 SECONDI
    mai visto una risposta così precisa ad un problema che a me sembrava così strano!!

    Per curiosità adesso provo ad applicare anche alla lettura dal file locale (mi salvavo il codice per averlo anche offline) lo stringbuffer e vedo se va alla velocità della luce come l'altro...

    Grazie mille!

  4. #4
    Se quel codice non deve essere Thread Safe usa meglio StringBuilder (alter ego di StringBuffer), dovrebbe essere ancora un po più veloce di StringBuffer in quanto non gestisce l'accesso condiviso da più Thread.

  5. #5
    Ovviamente anche la lettura da locale adesso è un fulmine l'exe invece rimane lento (ora non avanza proiprio...), pensavo che exe4j semplicemente lo avvolgesse in un exe e basta,facesse partire normalmente con java, ma non sono un esperto, e non è indispensabile il file exe, era solo per comodità... il problema del thread safe è il rischio di accedere contemporaneamente se non sbaglio? Non dovrebbe esserci questo rischio, adesso provo
    Perchè in tutti gli esempi di codice per scaricare da internet o leggere un file ho sempre trovato l'uso della classe String?

  6. #6
    Perché non molti sanno che la classe String è immutabile e che quindi la concatenazione di stringhe (specie in cicli) ha un consumo eccessivo di memoria che porta il GC a partire più volte per liberare la memoria usata.

  7. #7
    Grazie è più veloce StringBuffer comunque, sia da locale che dalla rete, in effetti nella documentazione di StringBuilder c'è scritto che è più veloce "nella maggior parte dei casi", non sempre, per provarlo ho semplicemente cambiato buff da StringBuffer a StringBuilder, mi pare basti fare quello, non ho toccato i metodi

  8. #8
    Per calcolare la velocità di entrambi, dato che cmq stai leggendo una risorsa che sia web o locale passa sempre per diverse cose (SERVER, SO), dovresti farlo girare un migliaio di volte per poi vedere i risultati di entrambi.
    Cmq StringBuilder è più veloce di StringBuffer.

  9. #9
    Utente di HTML.it
    Registrato dal
    Feb 2007
    Messaggi
    4,157
    Originariamente inviato da francesco.muia
    Perché non molti sanno che la classe String è immutabile e che quindi la concatenazione di stringhe (specie in cicli) ha un consumo eccessivo di memoria che porta il GC a partire più volte per liberare la memoria usata.
    e anche perché se si prevede che quel ciclo sia breve (cioè poche righe) non si ha un reale vantaggio nell'uso dello stringbuffer

    poi ti consiglio di vedere bene il fattore codepage, perché anche le replace sono un bello spreco


    ps un utente non vede visivamente la differenza tra StringBuilder/StringBuffer ad occhio nudo come hai visto quella tra StringBuffer/String.
    RTFM Read That F*** Manual!!!

  10. #10
    No infatti ho usato System.nanoTime() per misurare... il replace viene eseguito una sola volta è fuori dal ciclo quindi non mi pare uno spreco (se ho capito cosa intendi) per curiosità l'ho misurato sono 178346659 ns cioè 0,17 secondi (credo, accettabile per me)
    Ho rieseguito la lettura da file facendoli cento volte l'uno (Builder e Buffer) ed effettivamente è più veloce StringBuilder.
    Non riesco bene a capire la questione del codepage

    EDIT ovviamente postando codice html non compare negli esmpi adesso capisco cosa intendi xD i replace sono diversi, li modifico così si vedono

    codice:
     source=source.replaceAll(".",".");             source=source.replaceAll("& #58;",":");      
    source=source.replaceAll("& #8217;","'");    
    source=source.replaceAll("& #8230;","...");  
    source=source.replaceAll("& #8211;","-");    
    source=source.replaceAll("& #038;","&");

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.