L-am luat si eu si l-am pus..pare dragut el asa, dar e doar pt Intel si pe mine sincer ma enerveaza interfata Java-based..
Poate si din comoditate raman la ShakesPeer, cu toate minusurile lui..isi face totusi treaba bine si e nativ macar.
Aplicatie nativa OS X - Cocoa. Adica beneficiaza de toate facilitatile OS X nativ. Nu e Carbon de ex. sau portata sau multiplatform (Java de ex. - care in general mananca multe memorie, porneste lent si alte dezavantaje)
Scuze , acronimofilie (?) : ShakesPeer. Despre chestia cu Cocoa, așa e, am mai citit și ai dreptate, e mai bine să fie native. Rămân și eu tot la SP până una alta.
Ca tot esti utilizator de SP :p (SP era numele unei firme unde am lucrat inainte, de asta te intrebam - eram obisnuit cu prescurtarea), tu ai gasit solutie pt. Add Favourite User ? Adica sa iti retine un anumit user ? Juicy are asta ? Mie cam asta imi lipseste..sincer ca nu imi ia in perpendicular de la mai multi deodata nu ma deranjeaza deoarece trag bine de tot de la unul singur..si oricum are queue, stau toti la coada si daca nu imi place cum merge de la unul, iau de la urmatorul din lista.
Carbon este C/C++ chior, iar Cocoa este peste Objective C, cu wrappers la pointeri, cu garbage collection si alte prostioare de gen, care induc o oarecare penalitate de performanta. Carbon e mai “aproape” de procesor, de aici zicand “nativ” .
S-ar putea sa spun prostii, dar asta am citit pe jde site-uri vazand ca e mai lent Finder-ul Cocoa din Snow Leo. Totodata Eclipse SWT Cocoa (e in teste) are editorul text mult mai lent decat SWT-ul actual, care este Carbon based.
Overall, ce e clar este ca o aplicatie Cocoa este mai lenta (cel putin la partea de feel al UI-ului) fata de o aplicatie Carbon.
Cocoa is generally SLOWER than Carbon, despite what most public thinks. (When a Carbon app wants to call a function in itself, it jumps directly to the function address; when Cocoa app wants to do the same, it goes through a single (ok, there are a few variations of it) function called objc_msgSend which finds the correct address and jumps to there. This means each time a Cocoa method calls another Cocoa method there’s 16 to 80 instructions overhead compared to Carbon. A true bottleneck, however it is not a design flaw but rather a decision that makes objc quite flexible to make it achieve what it needs to).
Si se gaseste destul de mult pe net despre asta, dar e vorba de explicatie, de-asta am ales acest pasaj.
Unii zic că e un mit chestia asta cu “Carbon is faster”, din diverse motive. Pe mine mai puțin mă interesează aspectul ăsta, atâta timp cât practica demonstrează că probabil e mai ușor să faci un program care merge greu în Carbon decât în Cocoa. “Good programs are fast, poor programs are slow.”
Citeste comentariile mai jos. Omul spune ca nu e nicio problema ca ai 2-3 instructiuni (de fapt, vrea sa spuna function calls) in plus la un apel de functie (in Cocoa vs Carbon). De acord, dar asta inseamna multe instructiuni de procesor si vine un cetatean mai jos care ii explica faptul ca acele 2-3 instructiuni in plus cand ai zeci de mii de call-uri de functie (un lucru firesc la o aplicatie) inseamna enorm. Nu astea sunt cuvintele, am adaptat eu putin.
O ordine a performantei ar fi cam asa: Cod masina => Low level programming (unde se poate, bypass system calls cand desenezi) => Carbon => Cocoa => VM-uri (Java, .NET).
Cocoa ar putea fi asemanat cu Parallels sau VMWare, unde codul se executa la full speed pe procesor, dar orice I/O, care il scoate din sandbox, costa enorm.
Java si .NET sunt un fel de Rosetta (layer-ul de emulare PPC de pe Intel Macs), adica emulare full de procesor si, ca optimizare, JIT.
Inca o data, ca subiectiv, Finder-ul din Snow Leopard este vizibil mai lent decat Finder-ul actual. Marea realizare a Apple, se stie, este ca Finder-ul din Snow este portat pe Cocoa.
Finder a fost componenta cea mai criticată din Mac OS X pe motiv că e foarte lent. Mi-e greu să cred că cel din Snow Leopard va fi și mai lent decât ăsta. Nu are cum, nu are voie, indiferent cum l-or scrie.
