Alexei Alexandrov wrote:
> Hi Bram Moolenaar, you wrote:
>
> >
> > It sounds like keeping only 1024 bytes would already work for most
> > situations. That would be an acceptable amount to keep allocated at
> > all times. So why don't we use this as the initial size, and when it
> > grows larg
Hi Bram Moolenaar, you wrote:
>
> It sounds like keeping only 1024 bytes would already work for most
> situations. That would be an acceptable amount to keep allocated at
> all times. So why don't we use this as the initial size, and when it
> grows larger we free it when finished. The growth
Alexei Alexandrov wrote:
> > This sounds like a bug in getc(). It should know that only one thread
> > is reading the file and skip the locking. I don't think we should fix
> > library bugs in Vim, unless it's crashing or another significant problem.
> >
> It can't be a bug. I might be missing
Hi Bram Moolenaar, you wrote:
>> It's Windows, but on Linux it should be similar.
>
> I would not assume it's similar until there is proof.
>
Of course. I'm going to investigate it there.
>
> This sounds like a bug in getc(). It should know that only one thread
> is reading the file and skip
Alexei Alexandrov wrote:
> I've also noticed that Vim spends somewhat significant time on startup
> loading spell files (I have 2 languages in my .vimrc: set
> spelllang=en,ru). The time is mostly spent in
> EnterCriticalSection/LeaveCriticalSection with getc() upper the stack.
> The reason for t
On 2/8/07, Alexei Alexandrov <[EMAIL PROTECTED]> wrote:
> When testing it with VST it gave 3.4% speed improvements (the same
> metodology - 3 tests before and after, choose the best results).
Well, it's not that much but it's still positive result. :-)
Considering how intense these computat
Hi Mikolaj Machowski, you wrote:
>
> When testing it with VST it gave 3.4% speed improvements (the same
> metodology - 3 tests before and after, choose the best results).
>
Well, it's not that much but it's still positive result. :-)
--
Alexei Alexandrov
Dnia środa 07 luty 2007, Alexei Alexandrov napisał:
> Hi Mikolaj Machowski, you wrote:
> > Nice work. Could you send or place somewhere patches? I'd like to test
> > them on more complex regexps.
>
> Here it is. Note that the biggest speed-up is observed when regexp is
> matched a lot of times. The
Hi Alexei Alexandrov, you wrote:
>
> The program which confirms these numbers is attached.
>
Forgot the attachment.
--
Alexei Alexandrov
test_cs.c
Description: Binary data
Hi George V. Reilly, you wrote:
>
> How did you measure the time in EnterCriticalSection and
> LeaveCriticalSection?
I discovered the problem by using a performance tuning tool which uses sampling
approach to get statistical profile data. The intrusivity of this class of
tools is very low. I
Hi George V. Reilly, you wrote:
>
> How did you measure the time in EnterCriticalSection and
> LeaveCriticalSection?
>
I discovered the problem by using a performance tuning tool which uses sampling
approach to get statistical profile data. The intrusivity of this class of
tools is very low.
Alexei Alexandrov wrote:
I've also noticed that Vim spends somewhat significant time on startup loading
spell files (I have 2 languages in my .vimrc: set spelllang=en,ru). The time is
mostly spent in EnterCriticalSection/LeaveCriticalSection with getc() upper the
stack. The reason for this is
Hi Alexei Alexandrov, you wrote:
> Hi Bram et al.,
>
> I'm doing some performance investigations of Vim code trying to understand
> whether there are any possibilities to improve it.
I've also noticed that Vim spends somewhat significant time on startup loading
spell files (I have 2 languages i
Hi Mikolaj Machowski, you wrote:
> Nice work. Could you send or place somewhere patches? I'd like to test
> them on more complex regexps.
Here it is. Note that the biggest speed-up is observed when regexp is matched a
lot of times. The regexp mechanism itself is not affected at all here - so if
Hello,
Nice work. Could you send or place somewhere patches? I'd like to test
them on more complex regexps.
TIA
m.
Alexei Alexandrov wrote:
> OK. Platform used for investigations: x86, Windows XP SP 2. Pentium 4
> Northwood, 2.4 GHz, 512M RAM.
> I did 2 things: understanding stack usage and performance measurement.
> To understand the stack usage I added some simple logging to regexp.c:
> printing ga_maxlen b
Hi Bram Moolenaar, you wrote:
>
> Speed should be OK this way, but it does keep up to 32 Kbyte allocated.
> That may not seem much, but if we do this in many places it quickly adds
> up.
Any "keep limit" greater than initial size (e.g. 16384 bytes) will give the
same effect in many cases. By "m
Alexei Alexandrov wrote:
> >
> > The idea to gradually increase the chunk size makes sense, but not
> > everywhere. For the syntax stack it's probably better to start with a
> > stack that is mostly needed, then growing quite quickly (say double the
> > chunk size every time). That's because wh
On 2/4/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
Gnu malloc (glibc) is exceptionally fast, iirc.
Yes. It's based on Doug Lea's malloc:
http://gee.cs.oswego.edu/dl/html/malloc.html
nikolai
On 2/4/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Alexei Alexandrov wrote:
> I'm doing some performance investigations of Vim code trying to
> understand whether there are any possibilities to improve it.
> Currently I've made the following observations (all investigations are
> done on Wind
Alexei Alexandrov wrote:
> I'm doing some performance investigations of Vim code trying to
> understand whether there are any possibilities to improve it.
> Currently I've made the following observations (all investigations are
> done on Windows):
>
> Redundant work is done during regexp operati
On Thu, Feb 01, 2007 at 11:20:16PM +0300, Alexei Alexandrov wrote:
> Hi Bram et al.,
>
> I'm doing some performance investigations of Vim code trying to understand
> whether there are any possibilities to improve it.
> Currently I've made the following observations (all investigations are done
>
Hi Bram et al.,
I'm doing some performance investigations of Vim code trying to understand
whether there are any possibilities to improve it.
Currently I've made the following observations (all investigations are done on
Windows):
Redundant work is done during regexp operations in syntax highli
23 matches
Mail list logo
