Re: Another patch for 1.6.x
Stephan Witt wrote: I have another patch in my local branch checkout... It fixes a warning and a potential bug. OK. Jürgen
Re: Another patch for 1.6.x
Stephan Witt wrote: > I have another patch in my local branch checkout... > It fixes a warning and a potential bug. OK. Jürgen
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John McCabe-Dansted wrote: John If LyX locked files which were open in a still running LyX John process, that would have saved me some confusion. Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that Another LyX window has this file open and offer some of the following alternatives: * Do not open. fine * Open read only. fine * Open anyway. fine, assume the user sorts it out after being warned * Attempt to kill other LyX window. How? Killing the process is no good, that process may have several unsaved documents open. And it might belong to another user anyway. Helge Hafting
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc Anyway, I have an additional patch for this bug. Anyone Jean-Marc disagrees? Applied. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Helge Hafting [EMAIL PROTECTED] writes: | John McCabe-Dansted wrote: | | John If LyX locked files which were open in a still running LyX | John process, that would have saved me some confusion. | | Yes, but I am sure this can cause a lot of confusion too... | | | I am not sure why this would cause confusion. You could have a dialog | box warning that Another LyX window has this file open and offer | some of the following alternatives: | | * Do not open. | | fine | | * Open read only. | | fine | | * Open anyway. | | fine, assume the user sorts it out after being warned Please have a look at how emacs does this. (I am in favor of the 'when in doubt do as emacs' camp.) -- Lgb
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Please have a look at how emacs does this. (I am in favor of the Lars 'when in doubt do as emacs' camp.) It uses a ~/.emacs-places file which contains a list of files and offsets. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John McCabe-Dansted wrote: John> If LyX locked files which were open in a still running LyX John> process, that would have saved me some confusion. Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that "Another LyX window has this file open" and offer some of the following alternatives: * Do not open. fine * Open read only. fine * Open anyway. fine, assume the user sorts it out after being warned * Attempt to kill other LyX window. How? Killing the process is no good, that process may have several unsaved documents open. And it might belong to another user anyway. Helge Hafting
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> Anyway, I have an additional patch for this bug. Anyone Jean-Marc> disagrees? Applied. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Helge Hafting <[EMAIL PROTECTED]> writes: | John McCabe-Dansted wrote: | | >>John> If LyX locked files which were open in a still running LyX | >>John> process, that would have saved me some confusion. | >> | >>Yes, but I am sure this can cause a lot of confusion too... | >> | > | >I am not sure why this would cause confusion. You could have a dialog | >box warning that "Another LyX window has this file open" and offer | >some of the following alternatives: | > | >* Do not open. | > | fine | | >* Open read only. | > | fine | | >* Open anyway. | > | fine, assume the user sorts it out after being warned Please have a look at how emacs does this. (I am in favor of the 'when in doubt do as emacs' camp.) -- Lgb
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Please have a look at how emacs does this. (I am in favor of the Lars> 'when in doubt do as emacs' camp.) It uses a ~/.emacs-places file which contains a list of files and offsets. JMarc
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John If LyX locked files which were open in a still running LyX John process, that would have saved me some confusion. Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that Another LyX window has this file open and offer some of the following alternatives: * Do not open. * Open read only. * Open anyway. * Attempt to kill other LyX window. -- John C. McCabe-Dansted Master's Student
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> John> If LyX locked files which were open in a still running LyX > John> process, that would have saved me some confusion. > > Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that "Another LyX window has this file open" and offer some of the following alternatives: * Do not open. * Open read only. * Open anyway. * Attempt to kill other LyX window. -- John C. McCabe-Dansted Master's Student
Re: another patch...
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: Asger Regarding improving the performance: I can only recommend using Asger gprof. It's very easy, and it really helps when you want to Asger find and address bottlenecks. Yes, profiling is often a better idea than trying to guess where time is lost. Nevertheless, since we know without profiling that font loading is terribly slow, couldn't we cache the font metrics between runs like wine (for example) does? I'm sure the gain would be important. JMarc
Re: another patch...
"Mike" == [EMAIL PROTECTED] writes: Mike On 5 Mar 2001, Jean-Marc Lasgouttes wrote: I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... Mike This wins the "Cool Typo" award. When reading your (the Mike developers') discussions of compilers, pragmas, etc. my head Mike spins enough that you may as well be benchmarking in "successive Mike runes" Yes, that's what we are doing actually, but don't tell! JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: | | Asger Regarding improving the performance: I can only recommend using | Asger gprof. It's very easy, and it really helps when you want to | Asger find and address bottlenecks. | | Yes, profiling is often a better idea than trying to guess where time | is lost. | | Nevertheless, since we know without profiling that font loading is | terribly slow, couldn't we cache the font metrics between runs like | wine (for example) does? I'm sure the gain would be important. I think my lazy generation of LyXText could help on that. then we should only load the font metrics when first needed. Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I think my lazy generation of LyXText could help on that. then Lars we should only load the font metrics when first needed. Stupid question: are we forced to load the whole font metrics to use a font? If not, caching would be a gain. JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars I think my lazy generation of LyXText could help on that. then | Lars we should only load the font metrics when first needed. | | Stupid question: are we forced to load the whole font metrics to use a | font? If not, caching would be a gain. Yes, I belive so. part of the unicode addition to XFree86 have some changes to this, but I have no details. Lgb
Re: another patch...
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: Asger> Regarding improving the performance: I can only recommend using Asger> gprof. It's very easy, and it really helps when you want to Asger> find and address bottlenecks. Yes, profiling is often a better idea than trying to guess where time is lost. Nevertheless, since we know without profiling that font loading is terribly slow, couldn't we cache the font metrics between runs like wine (for example) does? I'm sure the gain would be important. JMarc
Re: another patch...
> "Mike" == <[EMAIL PROTECTED]> writes: Mike> On 5 Mar 2001, Jean-Marc Lasgouttes wrote: >> I tried the "benchmark" a bit here, and the times in successive >> rune fluctuate enough that I do not see how you can interpret >> them... Mike> This wins the "Cool Typo" award. When reading your (the Mike> developers') discussions of compilers, pragmas, etc. my head Mike> spins enough that you may as well be benchmarking in "successive Mike> runes" Yes, that's what we are doing actually, but don't tell! JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: | | Asger> Regarding improving the performance: I can only recommend using | Asger> gprof. It's very easy, and it really helps when you want to | Asger> find and address bottlenecks. | | Yes, profiling is often a better idea than trying to guess where time | is lost. | | Nevertheless, since we know without profiling that font loading is | terribly slow, couldn't we cache the font metrics between runs like | wine (for example) does? I'm sure the gain would be important. I think my lazy generation of LyXText could help on that. then we should only load the font metrics when first needed. Lgb
Re: another patch...
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I think my lazy generation of LyXText could help on that. then Lars> we should only load the font metrics when first needed. Stupid question: are we forced to load the whole font metrics to use a font? If not, caching would be a gain. JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> I think my lazy generation of LyXText could help on that. then | Lars> we should only load the font metrics when first needed. | | Stupid question: are we forced to load the whole font metrics to use a | font? If not, caching would be a gain. Yes, I belive so. part of the unicode addition to XFree86 have some changes to this, but I have no details. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjnnes wrote: | | | This patch includes the previous one and adds the same memore saving | as with the paragraph parameters, but now also for LyXFont. | | It raises binary size a bit more than I would like, but the memory | footprint for Userguide is now ~500 Kb. | | Comments? | | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). Yes, I see the same here. So we have to decide if this is a slow down that we can live with. (on the cell phone the numbers above came out as 218 and 27 and I got really worried...) btw. by also having language in fontbits we can save 4 bytes more for each LyXFont in use. This brings the size of LyXFont down from 44 bytes to 8 bytes. Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Yes, I see the same here. So we have to decide if this is a slow Lars down that we can live with. (on the cell phone the numbers above Lars came out as 218 and 27 and I got really worried...) Where does the slowdown come from? The ShareContainer::get method? Concerning this ShareContainer template, an obvious question: isn't there a better container than vector for this kind of stuff (a map?). Or could we order the contents of the container so that the most requested items come first? All in all, the patch looks nice, but the slow down (especially on UserGuide.lyx, which is a useful file in its own right) is a problem... JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars Yes, I see the same here. So we have to decide if this is a slow | Lars down that we can live with. (on the cell phone the numbers above | Lars came out as 218 and 27 and I got really worried...) | | Where does the slowdown come from? The ShareContainer::get method? | Concerning this ShareContainer template, an obvious question: isn't | there a better container than vector for this kind of stuff (a map?). | Or could we order the contents of the container so that the most | requested items come first? A map is not very good since we don't have a obvious key (for the same reason a hash_map would be hard to use since a hash function would be hard to get fast/right/uniue). I agree that the linear search is not good. (and this is what causes the slowdown I belive, (also that we clean the container very often)) Prefferably the clean should be moved into the get, but I am a bit afraid that this can cause wrong behaviour, I have to think a bit more on that. Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Yes, I see the same here. So we have to decide if this is a slow
Lars down that we can live with. (on the cell phone the numbers above
Lars came out as 218 and 27 and I got really worried...)
Where does the slowdown come from? The ShareContainer::get method?
Concerning this ShareContainer template, an obvious question: isn't
there a better container than vector for this kind of stuff (a map?).
Or could we order the contents of the container so that the most
requested items come first?
The problem is that the data in a LyXText instance is changed frequently
(in the LyXParagraph::GetFont and LyXText::GetFont methods).
The solution is perhaps to keep the LyXFont class unchanged, but in
LyXParagraph::FontTable store a boost::shared_ptrLyXFont
instead of a LyXFont.
btw. by also having language in fontbits we can save 4 bytes more for
each LyXFont in use. This brings the size of LyXFont down from 44
bytes to 8 bytes.
Another option (without using shared_ptr) is to change the members in
FontBits to chars (i.e. struct FontBits { char family; char series; ...})
This is a bit ugly, but at least it will give a memory reduction, without a
slowdown.
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes:
| On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars Yes, I see the same here. So we have to decide if this is a slow
| Lars down that we can live with. (on the cell phone the numbers above
| Lars came out as 218 and 27 and I got really worried...)
|
| Where does the slowdown come from? The ShareContainer::get method?
| Concerning this ShareContainer template, an obvious question: isn't
| there a better container than vector for this kind of stuff (a map?).
| Or could we order the contents of the container so that the most
| requested items come first?
|
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptrLyXFont
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
| btw. by also having language in fontbits we can save 4 bytes more for
| each LyXFont in use. This brings the size of LyXFont down from 44
| bytes to 8 bytes.
|
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 01:24:24PM +0100, Lars Gullik Bjønnes wrote:
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptrLyXFont
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
Why?
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
IIRC, we had something else: all the data was packed into a single unsigned
int, and that was indeed horrible.
With my suggestion it is not harder to maintain than the current code.
And you don't loose the type information because the interface method
(family(), series() etc.) do return the correct type.
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | A map is not very good since we don't have a obvious key (for the same | reason a hash_map would be hard to use since a hash function would be | hard to get fast/right/uniue). | | I agree that the linear search is not good. (and this is what causes | the slowdown I belive, (also that we clean the container very | often)) we can sort the vector on the use_count of the shared_ptr. Then the items that is used by the most will be found first. Hmm... but we cannot use any of the other std::containers... but we can perhaps use a priority_queue (with a deque underneath). I'll do some other small changes first and then I will try that. I will send new patches as I make progress. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | Oh, we had that earlier, the code was close to impossible to maintain, | won't happen. and I'd hate to loose the type information. btw. clever | compilers are free to use a byte for most of those enums. | | IIRC, we had something else: all the data was packed into a single unsigned | int, and that was indeed horrible. (I know) | With my suggestion it is not harder to maintain than the current code. | And you don't loose the type information because the interface method | (family(), series() etc.) do return the correct type. You loose type information inside the LyXFont class. besides, I think I can speed it up quite a lot by changing when clean is done, and using a bit more clever container. Let's do that first. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.495s user0m5.880s sys 0m0.030s On a PIII 700Mhz (with primed cache) without the primed cache it is ~13s. This is by moving the clean to another place. Lgb
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x 'lyx-quit' | | real0m8.495s | user0m5.880s | sys 0m0.030s | | On a PIII 700Mhz (with primed cache) With braindead use of push_heap: time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.515s user0m6.010s sys 0m0.050s Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x Lars lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x Lars 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | Lars On a PIII 700Mhz (with primed cache) Lars With braindead use of push_heap: Lars time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx Lars About to handle -x 'lyx-quit' Lars real 0m8.515s user 0m6.010s sys 0m0.050s I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... JMarc
Re: another patch...
"Jean-Marc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I tried the "benchmark" a bit here, and the times in Jean-Marc successive rune fluctuate enough that I do not see how you Jean-Marc can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars [EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | time ./src/lyx -x | Lars lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x | Lars 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | | Lars On a PIII 700Mhz (with primed cache) | | Lars With braindead use of push_heap: | | Lars time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | Lars About to handle -x 'lyx-quit' | | Lars real 0m8.515s user 0m6.010s sys 0m0.050s | | I tried the "benchmark" a bit here, and the times in successive rune | fluctuate enough that I do not see how you can interpret them... I never tried more than two runs in a row :-) Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
About to handle -x 'lyx-quit'
real0m8.515s
user0m6.010s
sys 0m0.050s
It still looks slow.
I still don't understand why we can't use my previous suggestion:
class FontTable {
public:
FontTable(size_type p, LyXFont const f) {
font_ = container.get(f);
container.clean();
}
LyXFont const font();
size_type pos();
private:
boost::shared_ptrLyXFont font_;
size_type pos_;
static ShareContainerLyXFont container;
};
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes:
| On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjnnes wrote:
| time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
| About to handle -x 'lyx-quit'
|
| real0m8.515s
| user0m6.010s
| sys 0m0.050s
|
| It still looks slow.
|
| I still don't understand why we can't use my previous suggestion:
|
| class FontTable {
| public:
| FontTable(size_type p, LyXFont const f) {
| font_ = container.get(f);
| container.clean();
| }
| LyXFont const font();
| size_type pos();
| private:
| boost::shared_ptrLyXFont font_;
| size_type pos_;
| static ShareContainerLyXFont container;
| };
Because I want to see if I can make the broader case faster first.
And your solution would benefit from this too.
Lgb
Re: another patch...
On 05-Mar-2001 Jean-Marc Lasgouttes wrote: Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs But this doesn't load a LyXText instance, does it? And there the Fonts are used most, isn't it? Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ By failing to prepare, you are preparing to fail.
Re: another patch...
On Mon, Mar 05, 2001 at 03:28:11PM +0100, Jean-Marc Lasgouttes wrote: "Jean-Marc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I tried the "benchmark" a bit here, and the times in Jean-Marc successive rune fluctuate enough that I do not see how you Jean-Marc can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs But this will not time the rendering pipeline (spiting the text to rows etc.) which is the part that causes the slowdown (I think).
Re: another patch...
Regarding improving the performance: I can only recommend using gprof. It's very easy, and it really helps when you want to find and address bottlenecks. Also, I must confess that it was me that introduced the ugly integer packed representation of the font information a long time ago. That was done because profiling showed it to be a huge gain, and at that point in time, it did in fact help. I understand that the structure is different today, so hopefully you won't have to revert to such a scheme again. Greets, Asger
Re: another patch...
On 5 Mar 2001, Jean-Marc Lasgouttes wrote: I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... This wins the "Cool Typo" award. When reading your (the developers') discussions of compilers, pragmas, etc. my head spins enough that you may as well be benchmarking in "successive runes", because I am certain that you are practicing spells and engaged in the black arts. Maybe it's time to support Peter Wilson's excellent archaic fonts, e.g. ctan:/tex-archive/fonts/archaic/runic. :-) Happy Monday! Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjønnes wrote: | > | > | > This patch includes the previous one and adds the same memore saving | > as with the paragraph parameters, but now also for LyXFont. | > | > It raises binary size a bit more than I would like, but the memory | > footprint for Userguide is now ~500 Kb. | > | > Comments? | | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). Yes, I see the same here. So we have to decide if this is a slow down that we can live with. (on the cell phone the numbers above came out as 218 and 27 and I got really worried...) btw. by also having language in fontbits we can save 4 bytes more for each LyXFont in use. This brings the size of LyXFont down from 44 bytes to 8 bytes. Lgb
Re: another patch...
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Yes, I see the same here. So we have to decide if this is a slow Lars> down that we can live with. (on the cell phone the numbers above Lars> came out as 218 and 27 and I got really worried...) Where does the slowdown come from? The ShareContainer::get method? Concerning this ShareContainer template, an obvious question: isn't there a better container than vector for this kind of stuff (a map?). Or could we order the contents of the container so that the most requested items come first? All in all, the patch looks nice, but the slow down (especially on UserGuide.lyx, which is a useful file in its own right) is a problem... JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Yes, I see the same here. So we have to decide if this is a slow | Lars> down that we can live with. (on the cell phone the numbers above | Lars> came out as 218 and 27 and I got really worried...) | | Where does the slowdown come from? The ShareContainer::get method? | Concerning this ShareContainer template, an obvious question: isn't | there a better container than vector for this kind of stuff (a map?). | Or could we order the contents of the container so that the most | requested items come first? A map is not very good since we don't have a obvious key (for the same reason a hash_map would be hard to use since a hash function would be hard to get fast/right/uniue). I agree that the linear search is not good. (and this is what causes the slowdown I belive, (also that we clean the container very often)) Prefferably the clean should be moved into the get, but I am a bit afraid that this can cause wrong behaviour, I have to think a bit more on that. Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Yes, I see the same here. So we have to decide if this is a slow
> Lars> down that we can live with. (on the cell phone the numbers above
> Lars> came out as 218 and 27 and I got really worried...)
>
> Where does the slowdown come from? The ShareContainer::get method?
> Concerning this ShareContainer template, an obvious question: isn't
> there a better container than vector for this kind of stuff (a map?).
> Or could we order the contents of the container so that the most
> requested items come first?
The problem is that the data in a LyXText instance is changed frequently
(in the LyXParagraph::GetFont and LyXText::GetFont methods).
The solution is perhaps to keep the LyXFont class unchanged, but in
LyXParagraph::FontTable store a boost::shared_ptr
instead of a LyXFont.
> btw. by also having language in fontbits we can save 4 bytes more for
> each LyXFont in use. This brings the size of LyXFont down from 44
> bytes to 8 bytes.
Another option (without using shared_ptr) is to change the members in
FontBits to chars (i.e. struct FontBits { char family; char series; ...})
This is a bit ugly, but at least it will give a memory reduction, without a
slowdown.
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> Yes, I see the same here. So we have to decide if this is a slow
| > Lars> down that we can live with. (on the cell phone the numbers above
| > Lars> came out as 218 and 27 and I got really worried...)
| >
| > Where does the slowdown come from? The ShareContainer::get method?
| > Concerning this ShareContainer template, an obvious question: isn't
| > there a better container than vector for this kind of stuff (a map?).
| > Or could we order the contents of the container so that the most
| > requested items come first?
|
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptr
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
| > btw. by also having language in fontbits we can save 4 bytes more for
| > each LyXFont in use. This brings the size of LyXFont down from 44
| > bytes to 8 bytes.
|
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 01:24:24PM +0100, Lars Gullik Bjønnes wrote:
> | The problem is that the data in a LyXText instance is changed frequently
> | (in the LyXParagraph::GetFont and LyXText::GetFont methods).
> | The solution is perhaps to keep the LyXFont class unchanged, but in
> | LyXParagraph::FontTable store a boost::shared_ptr
> | instead of a LyXFont.
>
> afaics it will be a lot harder then to localize the SharedContainer
> (functionality that will be needed to really save anything.)
Why?
> | Another option (without using shared_ptr) is to change the members in
> | FontBits to chars (i.e. struct FontBits { char family; char series; ...})
> | This is a bit ugly, but at least it will give a memory reduction, without a
> | slowdown.
>
> Oh, we had that earlier, the code was close to impossible to maintain,
> won't happen. and I'd hate to loose the type information. btw. clever
> compilers are free to use a byte for most of those enums.
IIRC, we had something else: all the data was packed into a single unsigned
int, and that was indeed horrible.
With my suggestion it is not harder to maintain than the current code.
And you don't loose the type information because the interface method
(family(), series() etc.) do return the correct type.
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | A map is not very good since we don't have a obvious key (for the same | reason a hash_map would be hard to use since a hash function would be | hard to get fast/right/uniue). | | I agree that the linear search is not good. (and this is what causes | the slowdown I belive, (also that we clean the container very | often)) we can sort the vector on the use_count of the shared_ptr. Then the items that is used by the most will be found first. Hmm... but we cannot use any of the other std::containers... but we can perhaps use a priority_queue (with a deque underneath). I'll do some other small changes first and then I will try that. I will send new patches as I make progress. Lgb
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes: | > Oh, we had that earlier, the code was close to impossible to maintain, | > won't happen. and I'd hate to loose the type information. btw. clever | > compilers are free to use a byte for most of those enums. | | IIRC, we had something else: all the data was packed into a single unsigned | int, and that was indeed horrible. (I know) | With my suggestion it is not harder to maintain than the current code. | And you don't loose the type information because the interface method | (family(), series() etc.) do return the correct type. You loose type information inside the LyXFont class. besides, I think I can speed it up quite a lot by changing when clean is done, and using a bit more clever container. Let's do that first. Lgb
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes: | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.495s user0m5.880s sys 0m0.030s On a PIII 700Mhz (with primed cache) without the primed cache it is ~13s. This is by moving the clean to another place. Lgb
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x 'lyx-quit' | | real0m8.495s | user0m5.880s | sys 0m0.030s | | On a PIII 700Mhz (with primed cache) With braindead use of push_heap: time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.515s user0m6.010s sys 0m0.050s Lgb
Re: another patch...
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x Lars> lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x Lars> 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | Lars> On a PIII 700Mhz (with primed cache) Lars> With braindead use of push_heap: Lars> time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx Lars> About to handle -x 'lyx-quit' Lars> real 0m8.515s user 0m6.010s sys 0m0.050s I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... JMarc
Re: another patch...
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> I tried the "benchmark" a bit here, and the times in Jean-Marc> successive rune fluctuate enough that I do not see how you Jean-Marc> can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x | Lars> lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x | Lars> 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | | Lars> On a PIII 700Mhz (with primed cache) | | Lars> With braindead use of push_heap: | | Lars> time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | Lars> About to handle -x 'lyx-quit' | | Lars> real 0m8.515s user 0m6.010s sys 0m0.050s | | I tried the "benchmark" a bit here, and the times in successive rune | fluctuate enough that I do not see how you can interpret them... I never tried more than two runs in a row :-) Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
> time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
> About to handle -x 'lyx-quit'
>
> real0m8.515s
> user0m6.010s
> sys 0m0.050s
It still looks slow.
I still don't understand why we can't use my previous suggestion:
class FontTable {
public:
FontTable(size_type p, LyXFont const & f) {
font_ = container.get(f);
container.clean();
}
LyXFont const & font();
size_type pos();
private:
boost::shared_ptr font_;
size_type pos_;
static ShareContainer container;
};
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
| > time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
| > About to handle -x 'lyx-quit'
| >
| > real0m8.515s
| > user0m6.010s
| > sys 0m0.050s
|
| It still looks slow.
|
| I still don't understand why we can't use my previous suggestion:
|
| class FontTable {
| public:
| FontTable(size_type p, LyXFont const & f) {
| font_ = container.get(f);
| container.clean();
| }
| LyXFont const & font();
| size_type pos();
| private:
| boost::shared_ptr font_;
| size_type pos_;
| static ShareContainer container;
| };
Because I want to see if I can make the broader case faster first.
And your solution would benefit from this too.
Lgb
Re: another patch...
On 05-Mar-2001 Jean-Marc Lasgouttes wrote: > Something like > time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx > seems to give more consistent results across runs But this doesn't load a LyXText instance, does it? And there the Fonts are used most, isn't it? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ By failing to prepare, you are preparing to fail.
Re: another patch...
On Mon, Mar 05, 2001 at 03:28:11PM +0100, Jean-Marc Lasgouttes wrote: > > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > Jean-Marc> I tried the "benchmark" a bit here, and the times in > Jean-Marc> successive rune fluctuate enough that I do not see how you > Jean-Marc> can interpret them... > > Something like > time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx > seems to give more consistent results across runs But this will not time the rendering pipeline (spiting the text to rows etc.) which is the part that causes the slowdown (I think).
Re: another patch...
Regarding improving the performance: I can only recommend using gprof. It's very easy, and it really helps when you want to find and address bottlenecks. Also, I must confess that it was me that introduced the ugly integer packed representation of the font information a long time ago. That was done because profiling showed it to be a huge gain, and at that point in time, it did in fact help. I understand that the structure is different today, so hopefully you won't have to revert to such a scheme again. Greets, Asger
Re: another patch...
On 5 Mar 2001, Jean-Marc Lasgouttes wrote: > I tried the "benchmark" a bit here, and the times in successive rune > fluctuate enough that I do not see how you can interpret them... This wins the "Cool Typo" award. When reading your (the developers') discussions of compilers, pragmas, etc. my head spins enough that you may as well be benchmarking in "successive runes", because I am certain that you are practicing spells and engaged in the black arts. Maybe it's time to support Peter Wilson's excellent archaic fonts, e.g. ctan:/tex-archive/fonts/archaic/runic. :-) Happy Monday! Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: another patch...
On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjønnes wrote: This patch includes the previous one and adds the same memore saving as with the paragraph parameters, but now also for LyXFont. It raises binary size a bit more than I would like, but the memory footprint for Userguide is now ~500 Kb. Comments? With the new patch, the Userguide loads very slowly: ~18 sec while with the old code (or the old patch) the UG loads in ~7sec (timed with 'time lyx -x lyx-quit UserGuide.lyx').
Re: another patch...
On Mon, 5 Mar 2001, Dekel Tsur wrote: [...] time lyx -x lyx-quit UserGuide.lyx Cool! A LyX Benchmark! Before too long we'll have a complete scripted benchmark and become the WinStone of the free software world ;-) Allan. (ARRae)
Re: another patch...
On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjønnes wrote: > > > This patch includes the previous one and adds the same memore saving > as with the paragraph parameters, but now also for LyXFont. > > It raises binary size a bit more than I would like, but the memory > footprint for Userguide is now ~500 Kb. > > Comments? With the new patch, the Userguide loads very slowly: ~18 sec while with the old code (or the old patch) the UG loads in ~7sec (timed with 'time lyx -x lyx-quit UserGuide.lyx').
Re: another patch...
On Mon, 5 Mar 2001, Dekel Tsur wrote: [...] > time lyx -x lyx-quit UserGuide.lyx Cool! A LyX Benchmark! Before too long we'll have a complete scripted benchmark and become the WinStone of the free software world ;-) Allan. (ARRae)
Re: Another patch
Dekel Tsur [EMAIL PROTECTED] writes: | This patch adds a file "lib/languages_strings" tha contains translations to | label strings (Figure, Abstract etc.). These translations are used to | translate the label strings according to the language of the paragraph (no | need to edit the layout files!). I don't want to apply these patches. Although this is a problem that we have it is the wrong solution. What we need is been able to have two locales open at the same time and two gettext sessions open at the same time. The file languages_strings.h should be an autogenerated file that xgettext will parse so that we will get those string too in the .po file. Lgb
Re: Another patch
Dekel Tsur <[EMAIL PROTECTED]> writes: | This patch adds a file "lib/languages_strings" tha contains translations to | label strings (Figure, Abstract etc.). These translations are used to | translate the label strings according to the language of the paragraph (no | need to edit the layout files!). I don't want to apply these patches. Although this is a problem that we have it is the wrong solution. What we need is been able to have two locales open at the same time and two gettext sessions open at the same time. The file languages_strings.h should be an autogenerated file that xgettext will parse so that we will get those string too in the .po file. Lgb
