> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> With the patch below:
Lars> Flat profile:
Excellent.
JMarc
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I felt that the layout lookup became a bit slow with the new layout as
| string stuff, so I did this patch. Is the added complexity worth it?
| (I cleaned up the textclass a bit as well...)
>
| all lookup functions has changed from O(n) to O(log n
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| Now, in this case, I would think that the distribution of lookups
| is such that the function will return the same value in 95% of
| all cases.
| Therefore, I believe you will get the best results by caching the
| last lookup, and then it i
On Tue, Mar 12, 2002 at 11:31:37AM +0100, Lars Gullik Bjønnes wrote:
> | Ok, maybe I did not make the point clear enough. cstring should only be
> | used when data is static, so copy is O(1) since it has to copy the pointer,
> | not the data.
>
> You then have a string that can be used for almost
On Mon, 11 Mar 2002, Lars Gullik Bjønnes wrote:
> all lookup functions has changed from O(n) to O(log n)
> delete_layout is still O(n), but with a higer constant factor.
> + typedef std::map LayoutMap;
Please note that std::map has a terrible constant factor in practically
all implementatio
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Mar 12, 2002 at 10:41:37AM +0100, Lars Gullik Bjønnes wrote:
>> I really do belive that the drawback with a cstring is a lot larger
>> than the drawbacks of string. cstring cannot store '\0', assignment is
>> always O(n) if you use dynamic alloc
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Mar 12, 2002 at 10:18:49AM +0100, Lars Gullik Bjønnes wrote:
>> >> There is also the possiblity of using a "tuning" lists, and list where
>> >> often used items are moved forward, so that lookup is faster next time
>> >> the same iterm is wanted
On Tue, Mar 12, 2002 at 10:41:37AM +0100, Lars Gullik Bjønnes wrote:
> I really do belive that the drawback with a cstring is a lot larger
> than the drawbacks of string. cstring cannot store '\0', assignment is
> always O(n) if you use dynamic allocation, it does not play well with
> std::string.
On Tue, Mar 12, 2002 at 10:18:49AM +0100, Lars Gullik Bjønnes wrote:
> >> There is also the possiblity of using a "tuning" lists, and list where
> >> often used items are moved forward, so that lookup is faster next time
> >> the same iterm is wanted, but is still O(n) in the general case.
>
> an
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Mar 12, 2002 at 10:08:29AM +0100, Lars Gullik Bjønnes wrote:
>> | cstring s("hello");
>> | cout << (s == "hello") << "\n";
>> | // i.e. syntax similar to std::string, but none of its overhead
>>
>> What overhead for const string?
>
| To b
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Mar 12, 2002 at 09:45:59AM +0100, Lars Gullik Bjønnes wrote:
>> In the lyxtextclass senario there is little a conststring class could
>> do... comparisons are O(n) on the string anyway.
>
| Worst case of course.
of course, and this is the case
On Tue, Mar 12, 2002 at 10:08:29AM +0100, Lars Gullik Bjønnes wrote:
> | cstring s("hello");
> | cout << (s == "hello") << "\n";
> | // i.e. syntax similar to std::string, but none of its overhead
>
> What overhead for const string?
To be able to use operator==()
> On speed you gain noth
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Mar 12, 2002 at 09:37:50AM +0100, Jean-Marc Lasgouttes wrote:
>> Andre> Apart from that I'd rather try to come up with some "really
>> Andre> fast" 'conststring' class which could improve most of the
>> Andre> handling of this 'strings used for
On Tue, Mar 12, 2002 at 09:45:59AM +0100, Lars Gullik Bjønnes wrote:
> In the lyxtextclass senario there is little a conststring class could
> do... comparisons are O(n) on the string anyway.
Worst case of course.
> One further optimization, over that patch that I sent, is to use a
> hash_map i
On Tue, Mar 12, 2002 at 09:37:50AM +0100, Jean-Marc Lasgouttes wrote:
> Andre> Apart from that I'd rather try to come up with some "really
> Andre> fast" 'conststring' class which could improve most of the
> Andre> handling of this 'strings used for convenience reasons' stuff,
> Andre> both for me
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
| Andre> On Mon, Mar 11, 2002 at 06:21:03PM +0100, Lars Gullik Bjønnes
| Andre> wrote:
>>> I felt that the layout lookup became a bit slow with the new layout
>>> as string stuff, so I d
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Mon, Mar 11, 2002 at 06:21:03PM +0100, Lars Gullik Bjønnes
Andre> wrote:
>> I felt that the layout lookup became a bit slow with the new layout
>> as string stuff, so I did this patch. Is the added complexity worth
>> it?
Did y
On Mon, Mar 11, 2002 at 06:21:03PM +0100, Lars Gullik Bjønnes wrote:
> I felt that the layout lookup became a bit slow with the new layout as
> string stuff, so I did this patch. Is the added complexity worth it?
Hm... I doubt that there is a lot of difference when there are just 30
items in the
I felt that the layout lookup became a bit slow with the new layout as
string stuff, so I did this patch. Is the added complexity worth it?
(I cleaned up the textclass a bit as well...)
all lookup functions has changed from O(n) to O(log n)
delete_layout is still O(n), but with a higer constant
19 matches
Mail list logo
