Mattias Gaertner schrieb:
At the moment the fpdoc editor is updated on idle in several steps.
Maybe the update should be started after a short delay.
Maybe. I'd suggest an thread, but I dunno about platform issues with
threads.
I also had an crash of lazde, caused by an formatting error in
Zitat von Hans-Peter Diettrich drdiettri...@aol.com:
Mattias Gaertner schrieb:
At the moment the fpdoc editor is updated on idle in several steps.
Maybe the update should be started after a short delay.
Maybe. I'd suggest an thread, but I dunno about platform issues with
threads.
Mattias Gärtner schrieb:
The problem is that many tools access the codetools (almost every file access
and search).
Then a request manager might help, with a busy indication so that a
client can skip and retry later. A threaded server will allow for higher
throughput on multi-core machines.
On Tue, Feb 24, 2009 at 05:43:37AM +0100, Hans-Peter Diettrich wrote:
I think the problem that is bigger than such a cache is mem management.
SynEdit keeps allocating/deallocating a lot = that leads to fragments
in the fpc mem-mgmt = and that could cause a slow down..
Now I could spot
On Tue, 24 Feb 2009 11:36:25 +0100
Marco van de Voort mar...@stack.nl wrote:
On Tue, Feb 24, 2009 at 05:43:37AM +0100, Hans-Peter Diettrich wrote:
I think the problem that is bigger than such a cache is mem
management. SynEdit keeps allocating/deallocating a lot = that
leads to
Mattias Gaertner schrieb:
What exactly is slow in fpdoc?
I guess he meant the fpdoc editor in the IDE, not the fpdoc program.
Right.
DoDi
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
Marco van de Voort schrieb:
Now I could spot the trouble source: it's fpdoc!
Interesting, I'm just optimizing a part of that.
http://bugs.freepascal.org/view.php?id=12953
What exactly is slow in fpdoc?
IMO it's the search for documentation information about the current
identifier in
Mattias Gaertner schrieb:
Now I could spot the trouble source: it's fpdoc!
Why do you think so?
When the fpdoc window is open, the task manager shows a CPU usage of up
to 100%, and every caret move can take several seconds. You can check
this behaviour yourself, my test case is the
On Tue, 24 Feb 2009 16:01:07 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Marco van de Voort schrieb:
Now I could spot the trouble source: it's fpdoc!
Interesting, I'm just optimizing a part of that.
http://bugs.freepascal.org/view.php?id=12953
What exactly is slow
Martin Friebe schrieb:
The effect is boring, even if I only navigate through the source code
with the cursor keys :-(
This bit sounds like a problem with painting the window.
Moving the cursor should not require much repaint. And after startup it
works fine, so that I suspect a
Hans-Peter Diettrich wrote:
Martin Friebe schrieb:
The effect is boring, even if I only navigate through the source code
with the cursor keys :-(
This bit sounds like a problem with painting the window.
Moving the cursor should not require much repaint. And after
- Memory management. SynEdit uses a TStrings attempt (IMHO a
gaped-buffer would be more efficient).
that's some kind of an urban legend.
But anyway I could cry aloud looking at what mwEdit became.
Nobody seems to know anymore how to write efficient code.
Martin
Martin Friebe schrieb:
Moving the cursor should not require much repaint. And after startup it
works fine, so that I suspect a problem with the information collected
over time.
yes and no:
- vertical moves do repaint the gutter always, in case that the every
nth line number is used.
Martin Waldenburg schrieb:
- Memory management. SynEdit uses a TStrings attempt (IMHO a
gaped-buffer would be more efficient).
that's some kind of an urban legend.
But anyway I could cry aloud looking at what mwEdit became.
Nobody seems to know anymore how to write efficient code.
Martin
Hans-Peter Diettrich wrote:
Martin Friebe schrieb:
Moving the cursor should not require much repaint. And after startup it
works fine, so that I suspect a problem with the information collected
over time.
yes and no:
- vertical moves do repaint the gutter always, in case
Hans-Peter Diettrich wrote:
Martin Waldenburg schrieb:
- Memory management. SynEdit uses a TStrings attempt (IMHO a
gaped-buffer would be more efficient).
that's some kind of an urban legend.
But anyway I could cry aloud looking at what mwEdit became.
Nobody seems to know
Martin Friebe schrieb:
I think the problem that is bigger than such a cache is mem management.
SynEdit keeps allocating/deallocating a lot = that leads to fragments
in the fpc mem-mgmt = and that could cause a slow down..
Now I could spot the trouble source: it's fpdoc!
DoDi
On Tue, 24 Feb 2009 05:43:37 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Martin Friebe schrieb:
I think the problem that is bigger than such a cache is mem
management. SynEdit keeps allocating/deallocating a lot = that
leads to fragments in the fpc mem-mgmt = and that could
Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
I can not work efficiently with Lazarus, due to two problems with the
editor (LazSynEdit): it can become dead slow, needing seconds of
computation for a single key stroke, and it doesn't support multiple
edit windows. This is why I
Martin Friebe schrieb:
I can not work efficiently with Lazarus, due to two problems with the
editor (LazSynEdit): it can become dead slow, needing seconds of
computation for a single key stroke, and it doesn't support multiple
edit windows. This is why I want to contribute to these issues,
Hans-Peter Diettrich wrote:
Martin Friebe schrieb:
If you use GTK1 or 2 you should use a font that is monospaces, and
exists in this size for bold and italic too. (And you must not use
ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet
this can not be compared to
21 matches
Mail list logo
