Re: A nasty inefficieny in file.c?

2006-07-15 Thread Jonathan Gordon
On 15/07/06, Magnus Holmgren [EMAIL PROTECTED] wrote: Jens Arnold wrote: Another thought: Are you listening to mp3? Iirc Slasheri said that the id3 parser is one such example of inefficiency as it reads byte-by-byte The id3 parser should read frame by frame, at least according to a

Re: A nasty inefficieny in file.c?

2006-07-15 Thread Jonathan Gordon
On 15/07/06, Jonathan Gordon [EMAIL PROTECTED] wrote: On 15/07/06, Magnus Holmgren [EMAIL PROTECTED] wrote: Jens Arnold wrote: Another thought: Are you listening to mp3? Iirc Slasheri said that the id3 parser is one such example of inefficiency as it reads byte-by-byte The id3

Re: A nasty inefficieny in file.c?

2006-07-15 Thread Linus Nielsen Feltzing
Jonathan Gordon wrote: // move the fd back to AFTER the \n if needed if (!errno) lseek(fd,num_read-count+1,SEEK_CUR); That could be a really lengthy operation if it crosses a sector boundary. Linus

Re: A nasty inefficieny in file.c?

2006-07-15 Thread Jonathan Gordon
grr, i cant get libsdl installed and that code definatly is no good, so dont bother trying yet :p to limit the distance it has to seek back would it be better to read the smaller of MAX_PATH and buffer_size untill either the buffer is full or we hit a new line? instead of just reading the full

Re: A nasty inefficieny in file.c?

2006-07-15 Thread Linus Nielsen Feltzing
Jonathan Gordon wrote: to limit the distance it has to seek back would it be better to read the smaller of MAX_PATH and buffer_size untill either the buffer is full or we hit a new line? instead of just reading the full buffer size? In any case, the read_line() inefficiency is not a big deal.