On Fri, 15 Jun 2007, Jonas Maebe wrote:
> > On 15 jun 2007, at 11:44, Michael Van Canneyt wrote: > > > >I'm sorry, but you are not providing enough information to give any useful > > >comments. There is no reason why a generic library would error out because > > >certain code is "too slow". Is this a real time application on an embedded > > >system or so? > > > >I think that the problem is the buffering. Just set the text buffer > >(settextbuf) to a larger buffer, and it should work a lot faster. > > That's quite unlikely to be the case. settextbuf seldomly makes a difference > for me. Especially if you write to standard output, which will trigger a flush > after every writeln anyway. > > >I don't see why not ? > >What would make it more slow than a comparable routine in libc ? > > Of course it is possible to write a routine which is just as fast as the one > in libc, but I'm not going to spend my time on that (I spent months on > debugging the current routine on different architectures to get consistent and > pretty correct output, and there are plenty of other more interesting and -as > far as I am concerned- important things to do). > > Currently, FPC's float->string conversion is apparently too slow for him > however, so FPC is not useful for him at this time if his main interest is > "speed of converting floating point numbers to string representation". Yes, but is there evidence that this is indeed the cause ? Because there are 2 mixed problems: writeln, and the conversion. You would have to test the speed of each of them separately to be able to say anything definitive. Like it is now, there is no indication that it is the float-to-text routine which is to blame. Michael. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal