1. Java / Говнокод #3135

    +75

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    private String getIdString() {
            String answer = Integer.toHexString(id.intValue());
            switch (answer.length()) {
            case 0:
                answer = "00000000";
                break;
            case 1:
                answer = "0000000" + answer;
                break;
            case 2:
                answer = "000000" + answer;
                break;
            case 3:
                answer = "00000" + answer;
                break;
            case 4:
                answer = "0000" + answer;
                break;
            case 5:
                answer = "000" + answer;
                break;
            case 6:
                answer = "00" + answer;
                break;
            case 7:
                answer = "0" + answer;
                break;
            }
            return answer;
        }

    JBoss Netty org.jboss.netty.channel.AbstractChannel

    Запостил: yvu, 30 Апреля 2010

    Комментарии (21) RSS

    • OMG, сам JBOSS
      Ответить
    • Максим Прохоров потрудился и над JBoss в том числе, а вы как думали
      Ответить
      • за Максимку свечку что ль поставить сходить
        Ответить
    • охщит, зачем нам прибегать к ужасно медленному String.format() , мы напишем свой велосипед, с коробкой передач и рельефной сидушкой
      Ответить
      • <с коробкой передач и рельефной сидушкой

        Отличная альтернатива блэкджеку и шлюхам.
        Ответить
    • Зато если им понадобится десять нулей спереди, простым Ctrl+C, Ctrl+V расширят функционал. Молодцы.
      Ответить
    • минусую. явно оптимизация. кто считает иначе - тому кочергой в ебло.
      Ответить
      • синтаксическую соль тебе в борщ!
        Ответить
      • А здесь она была нужна?
        Ответить
        • а как это можно определить по функции? только в контексте всего поделия. может, мне ещё сделать сервер, посидеть с профайлером, самому увидеть, что getIdString является боттлнеком (или не является)?

          на их странице:

          'Quick and easy' doesn't mean that a resulting application will suffer from a maintainability or a performance issue. Netty has been designed carefully with the experiences earned from the implementation of a lot of protocols such as FTP, SMTP, HTTP, and various binary and text-based legacy protocols. As a result, Netty has succeeded to find a way to achieve ease of development, performance, stability, and flexibility without a compromise.

          Performance

          * Better throughput, lower latency
          * Less resource consumption
          * Minimized unnecessary memory copy
          Ответить
      • Хреновая оптимизация. Я бы оптимизировал так:
        private String getIdString() {
        		String answer = Integer.toHexString(id.intValue());
        		StringBuilder sb = new StringBuilder("00000000");
        		sb.delete(8 - answer.length(), 8).append(answer);
        
        		return sb.toString();
        	}
        Ответить
        • исходников явы под рукой нет, поэтому поглядел дотнет.

          сабж имеет три действия (toHexString откинем): 1) свитч по длине 2) выделение памяти под строку 3) копирование из двух строк в новую с помощью вызова CharCopy дважды

          ваше предложение:

          1) выделить объект под стрингбилдер 2) один CharCopy на всю строку (по размеру цикла равно двум CharCopy в прошлом примере) 3) в append: если нужно (а скорей всего нужно), выделить новую строку и 4) в неё CharCopy содержимое предыдущей 5) возможен или вызов SubstringUnchecked, котрый выделяет память и CharCopy, или InternalSetLength, который проходится по всем чарам.

          Неужели в яве свитч такой медленный?..
          Ответить
          • > InternalSetLength, который проходится по всем чарам

            соврал, проходится по части.
            Ответить
          • Анализ Java-вского кода при помощи .Net - это сильно. В Java оператор + для String-ов реализован через неявное использование StringBuilder-а (в старых версиях - StringBuffer-а). Поэтому кроме использования StringBuilder#delete(int, int) вместо switch других отличий тут нет.
            Ответить
            • > Анализ Java-вского кода при помощи .Net - это сильно

              Такой вот я весельчак. Честно говоря, всё как в дотнете - так бы я сам реализовал. Именно такие алгоритмы, как там, приходят в голову в первую очередь...

              > Анализ Java-вского кода при помощи .Net - это сильно

              Вот это сильнее, чем профайлинг явы по дотнету. Не верю!
              Ответить
            • 2026:            public String concat(String str) {
              2027:                int otherLen = str.length();
              2028:                if (otherLen == 0) {
              2029:                    return this ;
              2030:                }
              2031:                char buf[] = new char[count + otherLen];
              2032:                getChars(0, count, buf, 0);
              2033:                str.getChars(0, otherLen, buf, count);
              2034:                return new String(0, count + otherLen, buf);
              2035:            }


              Чото не вижу я стрингбилдеров (jdk6). Или в говнояве оператор+ не мапится на concat?
              Ответить
              • Не видишь потому что не там смотришь. String#concat(String) имеет примерно такое же отношение к оператору +, как метод equals() к оператору ==. Увидеть реализацию оператора + для объектов можно только в дебагере.
                Ответить
                • Мда, ява хуже, чем я думал.

                  Пахнет говнокодом. Я ещё понимаю конкатенация ста строк. Но две?! Почему бы не маппить на Concat? У компилятора есть все средства соптимизировать.

                  В дотнете, например, для производительности специально перегрузили до 4 аргументов у Concat.

                  Как будто какому-то индусу было в лом написать пару условий, а потом оно случайно попало в спеки и для обратной совместимости так и осталось...
                  Ответить
    • Если так уж хотелось оптимизировать, не нужно было использовать toHexString...
      Что-нибудь в таком духе:
      String toHexString(int v)
      {
      int i = 8;
      char[] pool = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F};
      char[] result =  {'0', '0', '0', '0', '0', '0', '0', '0'};
      while (i > 0)
      {
      	if (v == 0) break;
      	result[i] = pool[v & 0xF];
      	v >>= 4;
      	i--;
      }
      return String.valueOf(result);
      }

      Сорри, не проверял, но уж всяко быстрее должно быть
      Ответить
    • Ну на крайняк так:
      public final String[] base = {"00000000","0000000","000000","00000"," 0000","000","00","0"};
      .....
      String answer = Integer.toHexString(id.intValue());
      answer = base[answer.length()] + answer;
      Ответить

    Добавить комментарий