¿ Cuánto consume un teléfono ?

Un teléfono solo, no sirve para comunicarse.

Sólamente puede comunicarse con otros, si es que existen otros y están encendidos; sino no.

Usualmente el consumo eléctrico se refiere a la medida de potencia, es decir, cuanta energía por segundo utiliza. Para saber esto, no alcanza con tener en cuenta un teléfono aislado, porque la existencia de los demás teléfonos es obligatoria (además del sistema de antenas, transmisores, etc.). Por lo tanto para que un teléfono cualquiera pueda comunicarse con otro cualquiera debe estar funcionando toda la red.

No es sencillo saber qué beneficios traen, pero sí podemos saber que la potencia que le exigimos al mundo para tener un celular es de miles de millones de Watts.

Optimización de algoritmos

Una sencilla idea para optimizar un algoritmo (para acelerar su ejecución) es dirigir el flujo chequeando las alternativas más específicas primero (lo menos probable primero), y las más generales después (lo más probable después).

Aún cuando la lógica fuera netamente combinacional, en un algoritmo las condiciones se evalúan secuencialmente, por lo tanto elegir el orden de esa evaluación teniendo en cuenta la probabilidad es fundamental para evitar evaluar repetidamente condiciones que fueran (casi) obvias.

Durante el diseño, por prolijidad e intuición, sin embargo, suele (y quizás deba) realizarse al revés, es decir pensar primero en generalidades poco específicas, ya que son útiles para agrupar y una vez probada la lógica puede pasarse a una versión optimizada.

Un ejemplo:

Top-Down (Para diseñar)

Si el siguiente algoritmo se ejecuta 1 vez por hora

  if(month == 12)
  {
      if(day == 31)
      {
          if(hour == 0)
          {
          }
      }
  }
  //Se suprimieron los "else" y cualquier código para simplificar la exposición

En un año chequeará el segundo "if", unas 31*24= 744 veces, y chequeará el tercero además 24 veces ( 768 tests )

Bottom-Up (Para optimizar)

Si el siguiente algoritmo se ejecuta 1 vez por hora

  if(hour == 0)
  {
      if(day == 31)
      {
          if(month == 12)
          {
          }
      }
  }

En un año chequeará el segundo "if", unas 365 veces, y chequeará el tercero además 1 sola vez ( 366 tests ).

Con este simple cambio hemos mejorado la eficiencia en más del 100%, es decir, que el segundo algoritmo podría ser el doble de rápido, consumirá la mitad de los recursos computacionales.

No podemos esperar que el compilador resuelva este tipo de optimizaciones porque no conoce la probabilidad de los resultados para cada condición (al menos en los lenguajes/compiladores actuales no permiten especificar tal probabilidad) cosa que podría ser útil.

Acelerar los navegadores de internet

Una forma de mejorar la rapidez de los navegadores
(Disminuir la cantidad de procesamiento, y ya que exageramos,
reducir el consumo mundial de energía)

Hacer que el parser de tags HTML sea Case Sensitive

Claro, debido a que el estándar no es Case Sensitive, el resultado sería
que muchas páginas no funcionen, es algo sabido que HTML
no es un formato que tenga como prioridad la rapidez, hasta es (casi) human readable!,
pero me pregunto, no será mejor que los Admins parseen y modifiquen
una sola vez en cada página de sus servidores con una aplicación tagsToUpperCase()
o tagsToLowerCase(), en lugar de hacer eso cada vez que se abre una página,
una y otra y otra vez, en todo el mundo. No parece tener mucho sentido.

El estándar XML que es posterior es Case Sensitive. Lo cual me parece muy bien.

¿Podés hablar?

La frase "¿Podés hablar?" intenta ser parte del protocolo de comunicación
para un llamado telefónico. Es un bug, y puede elminarse con una simple regla
(y así ganar millones de dolares, horas-hombre, etceteras, al rededor del mundo).

BugFix:

"Si no puede hablar, no atienda"

//
//Source.java
//

//...

try {

          if(puedeHablar())
          {
            atenderLlamado();
          }
          else
          {
             Thread.yield();
          }

    } catch(Exception ex)
     {
         System.out.println("Exceptions are exceptional (or they should be)");
     }