Формат за разпечатване

[JOKe]

popadna mi tazi statiika za vaprosi svyrzani s java poprincip e za stari versii na java otvreme na izlizaneto na 1.2 no dosta ot neshtata sam sa izkliuchitelno interesni i aktualni ZADALJITELNO da se prochete ot vseki javar ( i ne samo ) :
http://www.norvig.com/java-iaq.html
malka vmetka kakvo pishe tam : 
# hese were all done in 1998. Compilers have changed since then.
# Counting down (i.e. for (int i=n; i>0; i--)) is twice as fast as counting up: my machine can count down to 144 million in a second, but up to only 72 million.
# Calling Math.max(a,b) is 7 times slower than (a > b) ? a : b. This is the cost of a method call.
# Arrays are 15 to 30 times faster than Vectors. Hashtables are 2/3 as fast as Vectors.
# Using bitset.get(i) is 60 times slower than bits & 1 << i. This is the cost of a synchronized method call, mostly. Of course, if you want more than 64 bits, you can't use my bit-twiddling example. Here's a chart of times for getting and setting elements of various data structures:

i oshte milioni super interesni raboti pone spored men

[Nikolay Manchev]

Мда, това е забавно стига да не му вярваш особено. Едно време и аз пишех обратни цикли, щото JNZ е една инструкция, вместо местене на допълнителна стойност в регистър + CMP.  Обаче да ти кажа, след време се убедих че съвременните компилатори са доста интелигентни и сами правят тия оптимизация. Ако решиш да ги правиш ръчно, по-скоро ще объркаш компилатора и цялата инциатива ще има отрицателен, а не положителен ефект.

Поздрави,

Николай Манчев

[JOKe]

oki zareji tova za ciklite ;) ima nqkvi ideini neshta svyrzani s incializacionni blokove i izobshto a ve men lichno me nakefiha dosta ot neshtata za koito dori ne mi beshe hrumvalo che ima takiva hvatki.

[Stilgar]

zalagam 2 princesi, 1 kapi praskova, 2 paketa fastuci za tri i 3 vafli borovec, che Math.max se inline-va
ako v java ima inline obache
abe ako niama compilera shte go inline-ne

[Atanas Todorov]

По мои доста отдавнашни наблюдения най-големите митове и легенди в областта на програмирането и правенето на софтуер са тези, свързани с бързодействието (или performance-a)!

Повечето от тези "трикчета" наистина ще доведат до по-малко инструкции и ще спомогнат за ускоряването на приложението... но доколко?? Обикновено примерите са много изкуствени. Така например да вземем обхождане на List:

Код: [Маркирай кода]

1. for (int i = list.size() - 1; i >= 0 ; i--) {}
2. for (int i = 0; i < list.size(); i++) {}

Определено първият вариант ще е по-бърз (да речем 2 пъти). Причината би трябвало да е очевидна - N пъти се извиква метод (този за вземане на size()), но в дадения пример нищо не се прави в цикъла! (Ще вметна, че добър компилатор само в някои случаи би могъл да оптимизира кода така, че да избегне многократното извикване на метода.) Ама искам да попитам колко често на човек му се налага nonstop да обикаля някакъв многоброен List без (почти) нищо да прави с него? Обикновено в тялото на един цикъл има някакъв код и в повечето случаи той е това, което в действителност бави. Какво значение има дали .size() ще отнема 10ns, ако тялото на цикъла отнема микро- или мили-секунди? Достатъчно е да сложите само едно String str = "" + i; в тялото на цикъла или не дай си боже да принтите в конзолата и да видим каква ще бъде тогава относителната разлика в бързодействието...

И то тук говоря за size() - сиреч метод, т.е. нещо доста по-бавно от взимането стойността на променлива.

Отделен е въпросът, че при реалните приложения, това което наистина влияе на performance-а обикновено няма нищо общо с тези изолирани микро-примерчета. Това което е от съществено значение е свързано много повече с правилната архитектура и дизайн на приложението, а също и качеството и четимостта на кода ако щете. Да не говорим, че при повечето реални приложения обикновено се използват ралични API-та и технологии от по-високо ниво, които забавят performance-а на приложението в пъти (често с идеята да ускорят performance-а на разработчиците поне малко). Ако човек се концентрира върху "оптимизирането" на цикли и тем-подобни елементи от "крайната имплементация" чрез подобни трикчета, най-вероятно ще остане разочарован от крайния резултат.

Не ме разбирайте, че съм противник на идеята да се обръща внимание на това какъв точно код се пише. Напротив! Просто мисълта ми е, че не трябва нещата да се гледат под изкривена светлина и да се вадят грешни изводи. Твърдения от рода на това пък

Arrays are 15 to 30 times faster than Vectors

са толкова нелепи и некоректни сами по себе си, че както могат да разсмеят някои хора, така и доста да заблудят някой по-начинаещ програмист, решил, че призванието му е да пише мега бързи програми

Поздрави,

Наско

[Stilgar]

mda tova e kato ?: deto bilo po-burzo ot if else