Pagina 1 di 3

LAG ... se lo conosci lo eviti ...

MessaggioInviato: mer gen 23, 2008 9:28 am
di MartinGore
Volevo aprire un topic di tipo "brain storming" sul genere di quello aperto mesi fa sulla memoria.
L'oggetto è il LAG, questo mostro che infesta le nostre land.
Con l'ausilio di MarcoDuff (se ci sei betti un colpo) volevo esplorare alcune funzioni che lo stesso Marco ha tirato fuori in un post che ora non mi ritrovo.
Vorrei riuscire a capire come incidono alcune operazioni sul rendimento della land; ad esempio:
1) un timer che ogni 3 secondi lancia una httpRequest,
2) un sensore che scandisce la sua zona ogni 5 secondi,
etc. etc.

Marco illuminaci!

Re: LAG ... se lo conosci lo eviti ...

MessaggioInviato: mer gen 23, 2008 11:28 am
di MarcoDuff
MartinGore ha scritto:Volevo aprire un topic di tipo "brain storming" sul genere di quello aperto mesi fa sulla memoria.
L'oggetto è il LAG, questo mostro che infesta le nostre land.
Con l'ausilio di MarcoDuff (se ci sei betti un colpo) volevo esplorare alcune funzioni che lo stesso Marco ha tirato fuori in un post che ora non mi ritrovo.
Vorrei riuscire a capire come incidono alcune operazioni sul rendimento della land; ad esempio:
1) un timer che ogni 3 secondi lancia una httpRequest,
2) un sensore che scandisce la sua zona ogni 5 secondi,
etc. etc.

Marco illuminaci!


Argomento troppo difficile e soprattutto pochissimi strumenti per poterlo misurare in modo decente.

Ovviamente la cosa migliore è programmare con un pizzico di furbizia evitando di scrivere o fare cretinate assurte.

La pagina che consiglio a tutti di leggere è questa dove ci stanno tutti i consigli per ridurre il lag.

Per i casi specifici di cui parli tu:
- Il timer genera lag, addirittura i consigli sono di usarli in ordine di minuti e non di secondi... certo fare un llSetTimerEvent(0.04) genera parecchio lag (ma è anche stupida la persona che scrive quel codice).
- llHttpRequest non genera lag... il rallentamento è dovuto alla normale connessione tra due server in rete internet
- llSensor/llSensorRepeat ovviamente meno si usano meglio è. Ma la cosa assolutamente migliore è impostare più filtri possibile direttamente alla chiamata e ridurre il più possibile il range e l'arco.

Insomma... tutte cose quasi ovvie ma poco rispettate.

Re: LAG ... se lo conosci lo eviti ...

MessaggioInviato: mer gen 23, 2008 7:35 pm
di Opensource Obscure
MarcoDuff ha scritto:Insomma... tutte cose quasi ovvie ma poco rispettate.

io penso(spero) che anche per MartinGore queste cose fossero ovvie (lui e' un programmatore) e che lui intendesse .. portarle a conoscenza delle persone che gia' non le sanno. che probabilmente sono molte.

infatti in SL la percentuale di gente che usa gli script e' molto piu' alta di quella che programma in RL; ovvero, le cose ovvie per un programmatore RL non sono affatto ovvie per molte persone che _comunque_ in un modo o nell'altro metteranno degli script in funzione in SL. script che probabilmente laggheranno :-)

un po' come e' ovvio per un webdesigner usare immagini con un rapporto dimensioni/peso in KB appropriato al contesto in cui vengono inserite, in modo da non 'laggare il caricamento della pagina' - ma se apri una delle 50 milioni di pagine di MySpace troverai ovunque immagini in formato BMP, o immagini in alta risoluzione che vengono fatte apparire piu' piccole, o JPEG salvate in qualita' 12 in una scala da 1 a 10 (non e' una battuta, Photoshop permette di farlo...).

per cui la proposta di martin secondo me ha senso e la discussione (senza fretta) potrebbe proficuamente continuare a lungo.

io adesso inizio a leggermi quella pagina :-) grazie, intanto.

facciamo anche un elenco delle pagine utili?

http://www.lslwiki.net/lslwiki/wakka.php?wakka=Lag
http://www.secondlifeitalia.com/communi ... php?t=2892
http://www.secondlifeitalia.com/wiki/Lag

Re: LAG ... se lo conosci lo eviti ...

MessaggioInviato: mer gen 23, 2008 8:03 pm
di MarcoDuff
Opensource Obscure ha scritto:infatti in SL la percentuale di gente che usa gli script e' molto piu' alta di quella che programma in RL; ovvero, le cose ovvie per un programmatore RL non sono affatto ovvie per molte persone che _comunque_ in un modo o nell'altro metteranno degli script in funzione in SL. script che probabilmente laggheranno :-)


Su questo sono pienamente d'accordo con te.

Nella RL sono un Progettista di Sistemi Informativi e uno dei miei compiti più ardui è proprio la progettazione di software che non solo funzioni (e questo è semplice) ma che sia ottimizzato efficace ed efficiente (e questo non è per nulla semplice).

Da sempre sono stato un purista del codice, e saper programmare bene non è una cosa semplice... sfortunatamente serve parecchia esperienza e alcune nozioni. Uno dei libri più belli che ho letto è Head First Design Patterns, che consiglio in modo spassionato a tutti coloro che si vogliono cimentare nella programmazione/progettazione. E' un tipo di libro che non ti insegna come si risolve un problema ma come si affrontano i problemi e lo stile da usare per affrontarli.

Come si evita il lag? Semplice: basta acquisire un giusto stile di programmazione.
Come si impara lo stile? Semplice: con l'esperienza e confrontandosi con altre persone, non per forza esperte.
Confronto? Come? Semplice: ammiro quello che hai fatto tu, Open, un paio di volte: posti il tuo codice qui e lo sottoponi a tante persone più o meno esperte pronto a correggere i tuoi errori e quindi acquisendo sempre di più uno stile di programmazione.

Ma fino a quando la maggior parte delle persone vengono qui per chiedere la soluzione del problema (magari bella e servita) senza domandarsi il perchè di una soluzione o il "perchè usare il ciclo for invece del ciclo while" e soprattutto senza postare il codice finale... non si impara uno stile cosi!

Il forum, per fortuna, è frequentato da tantissime persone molto capaci nella programmazione LSL... ho girato molti forum, e questo luogo, non posso negarlo, è sicuramente il migliore italiano e tra i migliori al mondo (è risaputo che gli Italiani sotto il punto di vista della progettazione software sono tra i più stimati). Quello che manca a molti è la voglia di apprendere. Quindi la proposta di Martin è stupenda nell'idea, ma risolvibile solo se gli utenti si mettono a postare il codice da loro prodotto per migliorarlo.

Quindi POSTATE!

MessaggioInviato: mer gen 23, 2008 8:08 pm
di Alice Mastroianni
MArco è tutto in inglese...leggo, colgo qualche frase...mi rendo conto che anche le texture possono essere fautrici di lag oltre agli script ma..... ho un pò di difficoltà a cogliere tutto......e con il bubbler :9 em non ti dico cosa esce....


Però l'idea di Martin non è male, sarò felice di imparare da chi, come dice open, queste cose le sa perchè è la sua specializzazione.

E' un peccato infatti che alcune sim, anche ben fatte, siano praticamente inavvicinabili perchè il lag imperversa...ed è sconvolgente come altre volte....sim cariche di ogni cosa siano così navigabili che paia esserci il trucco.


Il mio quesito a voi esperti è :

Negozietto, diciamo un 20x20, già grande .
QUali gli accorgimenti per far si che gli script per il floating text, più le texture sui vari prodotti in vendita, più ipotizziamo un altro script pseudo segreteria telefonica o che invia notecard, ed ancora qualcosa che faccia girare le immagini random.

In questo caso (esempio negozio save the children a torino italy) mi son accorta che il negozietto lagga e nn poco e che quindi a molti passa la voglia di mettere a fuoco le immagini e leggere cosa vi è scritto.

Come potrei intervenire in questo caso?

Consideriamo che quegli script servono.... esiste il modo per utilizzarne uno per tutti? che so un unico script che capta quando tu tocchi un'immagine qualunque li dentro e ti lancia la notecard?

Sono follie quelle che chiedo?

MessaggioInviato: mer gen 23, 2008 8:35 pm
di MarcoDuff
Alice Mastroianni ha scritto:Marco è tutto in inglese...


Bhe... Gli Italiani sono i migliori... ma il materiale migliore è in inglese!
Sinceramente non so se esista una versione italiana del libro, tendo ad evitare i libri tecnici in Italiani... odio le traduzioni che fanno, molte sono peggio di bubbler!!!

Alice Mastroianni ha scritto:QUali gli accorgimenti per far si che gli script per il floating text, più le texture sui vari prodotti in vendita, più ipotizziamo un altro script pseudo segreteria telefonica o che invia notecard, ed ancora qualcosa che faccia girare le immagini random.

In questo caso (esempio negozio save the children a torino italy) mi son accorta che il negozietto lagga e nn poco e che quindi a molti passa la voglia di mettere a fuoco le immagini e leggere cosa vi è scritto.

Come potrei intervenire in questo caso?

Consideriamo che quegli script servono.... esiste il modo per utilizzarne uno per tutti? che so un unico script che capta quando tu tocchi un'immagine qualunque li dentro e ti lancia la notecard?

Sono follie quelle che chiedo?


Il floating text non genera lag sul serve e pochissimo lag sul client.
Sulle texture non ho capito una cosa: non so se esistono dei prefiltraggi quando vengono applicate (che so una immagine da 20MB applicata in un prim piccolissimo se viene ottimizzata o deve essere totalmente scaricata dal client, un poco il discorso di Open sui siti) ma in ogni caso non genera lag sul server e solo lag di connessione sul client (quindi un lag di basso livello, emule ciuccia molto di più!).

Script della segreteria:
- *DEVE* stare in uno stato idle sempre (ovvero in uno stato dove non deve fare assolutamente nulla)
- Appena cliccato si deve impostare in uno stato di ascolto con timeout (dopo tot secondi di non uso deve tornare allo stato idle) e attivare un listener con il massimo del filtraggio -> deve ascoltare solo chi l'ha attivata
- Bisogna ricordarsi di disattivare il timer nello state_exit. Al contrario dei listener lo stato di un timer è persistente (ovvero resta in memoria).
Il lag generato è assolutamente minimo se si usano questi piccoli trucchi.

Script invio notecard:
- Assolutamente banale. Invia la notecard dopo un touch_start.
Lag nullo!

Script per scorrere le immagini:
- Anche questo è banale, solo qualche accorgimento se si vuole fare anche uno scorrimeno manuale.
- Usare i pulsanti in prim esterni che comunicano tramite link_message
- Evitare comandi vocali o dialog (in ogni caso usare le dialog *solo* se bisogna risparmiare prim). In questo modo si evita l'uso di listener che sono pesanti e generano lag.
Lag basso.

Ma questi sono solo piccoli consigli... il tuo negozietto, con solo questi script NON dovrebbe generare lag... se lo genera vuol dire che ci sono altri script in land vicine o se ci sono porcate assurde scritte all'interno!

P.S.: Se qualcuno di voi si vuole cimentare nella scrittura di questi 3 script e sottoporsi al giudizio degli utenti... faccia pure!!! Cosa vince?Un bel post nella Hall of Fame: i post come Importanti in alto.

MessaggioInviato: mer gen 23, 2008 9:49 pm
di Spleen
MarcoDuff ha scritto:Sulle texture non ho capito una cosa: non so se esistono dei prefiltraggi quando vengono applicate (che so una immagine da 20MB applicata in un prim piccolissimo se viene ottimizzata o deve essere totalmente scaricata dal client, un poco il discorso di Open sui siti).

Tutta la texture viene scaricata in locale, ed in caso di perdita di pacchetti, può venir riscaricata più volte (c'e' un controllo di correttezza sulla dimensione totale dell'immagine che il client si aspetta).
Inoltre inizialmente vengono applicati i primi 600 byte della texture scaricata , da qui l'aspetto iniziale delle immagini sgranato.

MarcoDuff ha scritto:Bisogna ricordarsi di disattivare il timer nello state_exit. Al contrario dei listener lo stato di un timer è persistente (ovvero resta in memoria)..

Non sono sicuro di aver capito: intendi che se ho un timer attivo,passo ad uno altro stato e poi ritorno allo stato precedente il timer è nella situazione in cui lo avevo lasciato?

MessaggioInviato: mer gen 23, 2008 10:41 pm
di pavo_baxter
io ho postato in sezione scripting...ditemi là cosa ne pensate

MessaggioInviato: gio gen 24, 2008 12:19 am
di MartinGore
WOW!!!
non credevo che questo post avesse un tal successo ...
devi dire che mi cogliete impreparato ma sicuramente domani posto alcuni test sul lag per vedere ciò che si può apprendere dalle funzioni del LSL.
Magari ci creiamo un "LAG-Meter" ...

Concordo pienamente con i ragionamenti di Marco sullo stile e tranquillizzo Open in merito alle "ovvietà" di cui sopra.
Il punto però è che qui abbiamo a che fare con un NON-Linguaggio ... una sorta di brodo primordiale di bit con cui bisogna, lasciatemelo dire, LOTTARE!

Il post scaturisce in realtà dalla amara constatazione che l'uso della tecnica XMLRPC è assolutamente INAFFIDABILE!
Come qualcuno di voi saprà mi sono imbarcato in una avventura chemata Second Life Extender dove WEB-SL-Skype-SMS-EMail ... insomma dove tutta una serie di "canali" entrano in comunicazione.
Le COMUNICAZIONI questo è il punto di partenza di tutto il ragionamento.

Seguendo il pensiero di Marco, per ottenere del codice "efficace ed efficiente", per instaurare una comunicazione tra media differenti (Second Life e Skype per esempio) è buona norma adottare un paradigma "asincrono" ovvero: mando una richiesta, vengo attivato solo quando mi arriva la risposta.
Ebbene con XMLRPC qui in SL si "dovrebbe" riuscire a fare una cosa del genere (premetto che l'uso dell'Email, altro meccanismo asincrono, non è praticabile per situazioni che necessitano risposte "quasi" in tempo reale). AHIME' le funzioni sono inaffidabili dato che i messaggi arrivano più o meno quando gli pare.
Alchè non vi è alternativa ... ci vuole il caro e vecchio (ED AFFIDABILE) POLLING!!! Ovvero mando la richiesta e comincio a stressare il server chiedendo:
E' arrivata la risposta?
E' arrivata la risposta?
E' arrivata la risposta?
E' arrivata la risposta?
E' arrivata la risposta?
Finchè il server (che non dice le maleparole ma i bit che ogni tanto si perdono gli assomigliano tanto) alla fine risponde.
Ovvio è una ciofeca ma con un linguaggio ciofeca non puoi pretendere.
A questo punto entra in gioco l'estro del programmatore:
1) Studia il LAG, vedi che succede se metti un polling a 5sec, poi a 3sec, poi ad 1sec ...
2) inventati i peggio trucchi per rendere attivo lo script il minor tempo possibile
3) Ristudia il LAG ... magari invece di fare un triplo salto mortale carpiato ti basta una bella (e dolorosa) panciata ed il tutto gira (non in modo efficiente ed efficace ma gira).

Riassumendo, domani provo a mettere giù qualche test per verificare (più o meno) cosa vuol dire mettere un timer a 0.05 secondi piuttosto che a 5 secondi. Vedrò di capire un arcano che ritengo stupendo della documentazione "ufficiale" che consiglia di NON usare llSensorRepeat quindi (presumo) in una condizione di intercettazione degli Avatar dovrei mettere un llSensor dentro un timer (mah).
Insomma vediamo se riusciamo a tirar fuori qualcosa.

Per ora grazie della partecipazione PROAttiva e ... BUONANOTTE (dato che son le 23:21)

MessaggioInviato: gio gen 24, 2008 1:08 pm
di MarcoDuff
Spleen ha scritto:Non sono sicuro di aver capito: intendi che se ho un timer attivo,passo ad uno altro stato e poi ritorno allo stato precedente il timer è nella situazione in cui lo avevo lasciato?


Esatto.

http://www.lslwiki.net/lslwiki/wakka.ph ... TimerEvent

The timer persists over state changes, but gets removed when the script is reset.


Quindi se sei nello stato A ed imposti il timer in questo modo

llSetTimerEvent(60.0);

e dopo 50 secondi passi nello stato B e poi torni in A il timer riparte da 10 secondi.

Quindi in tutti quegli stati dove si utilizza un timer si dovrebbe usare (fatta eccezione per utilizzi particolari) il seguente codice:

Codice: Seleziona tutto
state_exit()
{
   llSetTimerEvent(0.0);
}

MessaggioInviato: gio gen 24, 2008 1:15 pm
di sisal
in assoluto quello che lagga di più una sim sono tutti gli oggetti scriptati indossati dagli avatar purtroppo

MessaggioInviato: gio gen 24, 2008 1:17 pm
di MarcoDuff
Per la comunicazione mondo -> SL, fammici pensare... mi sono imbattuto pure io in questo problema orrendo... alla fine ho scelto la strada della mail e l'oggetto che si continua a controllare per vedere se è arrivata qualche cosa (che bella porcata... era cosi semplice utilizzare il Pattern dell'Observer... ovvero appena arriva una mail notifica tramite l'evento email se definito, e non dare al client il compito di controllare <- significa errore di progettazione dell'LSL che genera lag).

Intanto ti rispondo a questo:

MartinGore ha scritto:Vedrò di capire un arcano che ritengo stupendo della documentazione "ufficiale" che consiglia di NON usare llSensorRepeat quindi (presumo) in una condizione di intercettazione degli Avatar dovrei mettere un llSensor dentro un timer (mah).


No, usare un llSensor dentro un timer significa emulare un llSensorRepeat. Si dovrebbe usare una schifezza tipo llVolumeDetect (un prim gigante quanto il range invisibile con llVolumeDetect attivato in modo da causare una collisione quando arriva un agent).... si, è una porcata ma il lag è 0 rispetto ad un sensore.

MessaggioInviato: gio gen 24, 2008 1:42 pm
di MartinGore
MarcoDuff ha scritto:Per la comunicazione mondo -> SL, fammici pensare... mi sono imbattuto pure io in questo problema orrendo... alla fine ho scelto la strada della mail e l'oggetto che si continua a controllare per vedere se è arrivata qualche cosa
...

Già ma il problema qui è che la comunicazione comunque deve essere in tempo (pseudo)reale.
I tempi di delivering della mail non sono accetabili.
Utilizzo questo metodo per comunicazioni ALTAMENTE asincrone dato che, facendo delle prove, a volte la mail arriva anche dopo 15 minuti!!!! :checosa:

MarcoDuff ha scritto:No, usare un llSensor dentro un timer significa emulare un llSensorRepeat. Si dovrebbe usare una schifezza tipo llVolumeDetect (un prim gigante quanto il range invisibile con llVolumeDetect attivato in modo da causare una collisione quando arriva un agent).... si, è una porcata ma il lag è 0 rispetto ad un sensore.

Esatto infatti l'arcano a cui mi riferivo è la seguente frase della documentazione:
Do you really need llSensorRepeat? Probably not. Use llSensor instead.

Come probably not???? se uso llSensor questo mi fa lo scan UNA volta e chi s'è visto s'è visto ... anzi mi chiedo la recondita utilità di un sensore che scandisce unatantum ... che **zzo di sensore è!?!?!?!?

MessaggioInviato: gio gen 24, 2008 2:54 pm
di MarcoDuff
MartinGore ha scritto:Già ma il problema qui è che la comunicazione comunque deve essere in tempo (pseudo)reale.
I tempi di delivering della mail non sono accetabili.
Utilizzo questo metodo per comunicazioni ALTAMENTE asincrone dato che, facendo delle prove, a volte la mail arriva anche dopo 15 minuti!!!! :checosa:


Penso (e sottolineo il penso) che questo dipenda più che altro dal server smtp che invia la mail.
Ho un server smtp locale nel mio pc, e tutte le volte che invio una mail ho tempi di latenza prossimi allo 0... e devo dire che non ho mai avuto problemi.
Ovvio che non è garantito il tempo reale non essendo una trasmissione ad hoc... quello che doveva risolvere il problema era proprio la Remote Procedure Call XML... che però risulta essere totalmente inutilizzabile!

MartinGore ha scritto:Come probably not???? se uso llSensor questo mi fa lo scan UNA volta e chi s'è visto s'è visto ... anzi mi chiedo la recondita utilità di un sensore che scandisce unatantum ... che **zzo di sensore è!?!?!?!?


Ti devo dire che ho utilizzato llSensor in alcune mie applicazioni. Mi serviva scatenarlo soltanto una volta in alcune condizioni particolari per la ricerca di oggetti in un'area ristretta.
Faccio l'esempio pratico:
ho creato un oggetto che crea in modo dinamico le stanze di una casa che funziona in questo modo:
- Tutti gli oggetti da salvare hanno un nome particolare (esempio: iniziano tutti con HomeSet)
- L'utente posiziona i vari oggetti in una posizione particolare e fa partire il comando per il salvataggio della posizione
- Partito il comando viene avviato il sensore una volta per la scansione della zona alla ricerca degli oggetti e la loro relativa posizione salvandola in una lista interna
In questo caso è ovvio l'utilizzo di un sensore unico invece di un sensore ripetuto... anche se capisco che il 99% delle volte che si usa un sensore lo si fa per una ripetizione!

MessaggioInviato: gio gen 24, 2008 3:42 pm
di MartinGore
MarcoDuff ha scritto:Penso (e sottolineo il penso) che questo dipenda più che altro dal server smtp che invia la mail.
Ho un server smtp locale nel mio pc, e tutte le volte che invio una mail ho tempi di latenza prossimi allo 0... e devo dire che non ho mai avuto problemi.
Ovvio che non è garantito il tempo reale non essendo una trasmissione ad hoc... quello che doveva risolvere il problema era proprio la Remote Procedure Call XML... che però risulta essere totalmente inutilizzabile!


In verità ho provato una miriade di server dal locale ad alcuni in rete.
In ogni caso è impredicibile, quindi inaffidabile, quindi non proponibile per una realizzazione "industriale".
XMLRPC funziona peggio dei giochetti elettronici di mio figlio ...
quindi ecco il caro e vecchio polling!!!!