<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Después de unos cuantos benckmarks (usando DateTime, POSIX::strptime, etc...), lo que mejor resultado me está dando es tirar directamente de POSIX::mktime partiendo "a mano" la fecha, tal que así:<br>
<br></blockquote><div><br></div><div>Pues este tema me he recordado de un artículo sobre el excelente buscador Blekko, que está hecho en Perl. En ello cuentan un poco su arquitectura y un problema de rendimiento con strftime() de C (invocado desde Perl, supongo). </div>
<div><br></div><div><a href="http://www.readwriteweb.com/hack/2010/12/the-secrets-behind-blekkos-search-technology.php">http://www.readwriteweb.com/hack/2010/12/the-secrets-behind-blekkos-search-technology.php</a></div><div>
<br></div><div>El problema, según parece, es que la función strftime() carga (y recarga a menudo) unos 50 ficheros de locale del sistema. Desconozco si mktime() sufre del mismo problema (lo dudo, al no tener que formatear fechas - o sí?). Con un lsof rápido de la ejecución de un perl sale que los ficheros de locale están cargados en memoria con o sin mktime...</div>
<div><br></div><div>La solución... en el artículo de Blekko no hay mención a cómo han solventado el problema. Supongo que vaporizando las llamadas a strftime()...</div><div><br></div><div>Yo optaría por crear una lookup table, cambiando memoria x cpu (si te lo puedes permitir y si tu script es persistente). Al arrancar tu script, carga un buen rango de fechas (sin los decimales y con el formato de origen) en un hash -- consultando la primera y última línea del log, si es lineal -- y sólo tira de unpack y mktime() si no encuentras la fecha en memoria. </div>
<div><br></div><div>saludos, </div><div> r</div></div><br>