<br><br><div class="gmail_quote">2008/4/24 Lucian Adrian Grijincu <<a href="mailto:lucian.grijincu@gmail.com">lucian.grijincu@gmail.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/4/24 Bogdan Bodistean <<a href="mailto:bogdanbodistean@gmail.com">bogdanbodistean@gmail.com</a>>:<br>
<div class="Ih2E3d">> daca am face in server direct un string-ul ce uremaza a fi printat si pus<br>
> apoi in memoria partajata atunci toti clientii care au de afisat nu mai<br>
> aproape nimic de facut . si ar fi mult mai eficient decat sa construiasca<br>
> fiecare client stringul. daca ati zice ca e din motive didactice nu as mai<br>
> avea ce sa spun, dar in cazul de fata tot nu vad care e eficenta.<br>
<br>
</div>daca formatul de afisare ducea la stringuri de mai mult de 7GB, cum<br>
mai tineai in memorie partajata afisarea?<br>
</blockquote></div><br><br>Pentru fiecare nod se adauga in string cel mult 11 bytes care reprezint numarul intreg in format de afisare plus un caracter pentru spatiu sau un caracter de sfarsit de linie, plus '*' care reprezinta un nod nul. asta inseamna in medie 14 bytes. O implementare normala a arborelui clasic poate contine un int pentru valoarea nodului plus inca doi int incare vor fi tinutii offset-ul pentru cei 2 copii. Deci s-a ajuns deja la 12 bytes garantat si daca cineva mai vrea sa tine un camp si pentru tata deja se depaseste. Pe cand string-ul poate fi mai mic daca nu sunt folosite doar numerele din limita superioara a int-ului. Deci daca nu poate fi folosit stringul in memoria partajata nici un arbore clasic cu mult mai mare nu ar putea fi tinut.<br>