25/03/2013 14:17, Vincent van Ravesteijn:
If needed, we can write it ourselves probably as well. Would be a nice
exercise for the reader ;).
At first I thought you were exaggerating, but it is actually a good idea.
JMarc
25/03/2013 20:58, Abdelrazak Younes:
On 25/03/2013 13:45, Jean-Marc Lasgouttes wrote:
Le 25/03/2013 12:07, Vincent van Ravesteijn a écrit :
Yes, I think we should. On Windows, it takes around 200-250usec to get a
translated message, while on Linux you estimated it as 5usec. So, the
issue might
On 25/03/2013 13:45, Jean-Marc Lasgouttes wrote:
Le 25/03/2013 12:07, Vincent van Ravesteijn a écrit :
Yes, I think we should. On Windows, it takes around 200-250usec to get a
translated message, while on Linux you estimated it as 5usec. So, the
issue might pop up in other situations as well, ev
>
>
>
> Interesting. Now I know why gettext is slow with windows. It is
> environment setting that takes all the time.
>
> This is because of the horrible API of gettext. We can need several
> different languages at the same time, and we cannot pass that as a
> parameter. Moreover, if we leave thes
Le 25/03/2013 12:07, Vincent van Ravesteijn a écrit :
Yes, I think we should. On Windows, it takes around 200-250usec to get a
translated message, while on Linux you estimated it as 5usec. So, the
issue might pop up in other situations as well, even though there are no
problems on Linux.
OK.
>
>
> With the fix, I can use LyX without the Messages cache and I hardly
>> notice any delays (compare this to the 2.6 second delay for each update
>> before).
>>
>
> This is pretty nice :) I was wondering how gettext could impair this much
> the performance. On linux GuiView::updateToolbars goes
Le 25/03/2013 10:41, Vincent van Ravesteijn a écrit :
OK, I am reading too fast, it seems. What does the performance look
like with your fix to format code?
We could of course define separate macros. One that uses system time
with millisecond resolution (for the reasons you mentioned), a
On Mon, Mar 25, 2013 at 10:29 AM, Jean-Marc Lasgouttes
wrote:
> Le 25/03/2013 10:23, Vincent van Ravesteijn a écrit :
>
>
>> Add a WIN32 equivalent for gettimeofday
>>
>> This function does not really returns the "time of day", but it
>> will suffice to evaluate elaps
Le 25/03/2013 10:23, Vincent van Ravesteijn a écrit :
Add a WIN32 equivalent for gettimeofday
This function does not really returns the "time of day", but it
will suffice to evaluate elapsed times.
What's wrong with using timeGetTime instead? The choice I mad
>
>
>> Add a WIN32 equivalent for gettimeofday
>>
>> This function does not really returns the "time of day", but it will
>> suffice to evaluate elapsed times.
>>
>
> What's wrong with using timeGetTime instead? The choice I made was to use
> plain time to count also the time used by other pro
Le 24/03/2013 16:47, Vincent van Ravesteijn a écrit :
The branch, master, has been updated.
- Log -
commit 367126bf245fb2399083a17fb1f8cffa8ed66f91
Author: Vincent van Ravesteijn
Date: Sun Mar 24 13:35:44 2013 +0100
Add a
11 matches
Mail list logo
