[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Performance degradation from long lines
From: |
Ihor Radchenko |
Subject: |
Re: Performance degradation from long lines |
Date: |
Fri, 26 Oct 2018 16:58:09 +0800 |
> Would it help to "say the same"?
> I'm trying to come up with ideas to help people get bearable
> performance in practical use cases. I can shut up if people don't
> want to hear about partial solutions that don't work in all cases.
> Assigning blame and/or venting steam will not help us make any
> progress in this area, you know.
Sorry, I meant no offence there.
I just wanted to say that, if possible, we should try to find
workarounds for non-file buffers.
Ideally, these workarounds should work in all the non-file buffers
without a need to address the issue for each buffer type separately.
Eli Zaretskii <address@hidden> writes:
>> From: Ihor Radchenko <address@hidden>
>> Cc: address@hidden, address@hidden
>> Date: Fri, 26 Oct 2018 16:05:25 +0800
>>
>> > Not in all cases, but certainly in some.
>>
>> I can say the same about the whole long lines problem.
>
> Would it help to "say the same"?
>
> I'm trying to come up with ideas to help people get bearable
> performance in practical use cases. I can shut up if people don't
> want to hear about partial solutions that don't work in all cases.
>
> Assigning blame and/or venting steam will not help us make any
> progress in this area, you know.
>
>> > How about asking Org developers to do something about these cases,
>> > like not using the entire buffer as a literal string argument, to
>> > avoid such problems?
>>
>> Well, in org-mode, the buffer is parsed into s-exp containing all the
>> buffer elements and the associated text, which can be even longer that
>> the buffer string itself.
>> So, the long line is what the parser returns.
>> This approach is a part of the core implementation of the org-mode and
>> cannot be changed easily.
>
> Then perhaps we could find a solution specific to backtrace buffers,
> like displaying ellipsis or a special button instead of too-long
> lines.
--
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: address@hidden, address@hidden
Tel: +6584017977
signature.asc
Description: PGP signature
- Re: Performance degradation from long lines, (continued)
- Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/26
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/26
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/26
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines,
Ihor Radchenko <=
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines, Noam Postavsky, 2018/10/26
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/26
- Re: Performance degradation from long lines, Stefan Monnier, 2018/10/26
- Re: Performance degradation from long lines, mithraeum, 2018/10/26
- Re: Performance degradation from long lines, mithraeum, 2018/10/26
- Re: Performance degradation from long lines, Gemini Lasswell, 2018/10/26
- Re: Performance degradation from long lines, Ihor Radchenko, 2018/10/31
- Re: Performance degradation from long lines, Eli Zaretskii, 2018/10/31
Re: Performance degradation from long lines, Clément Pit-Claudel, 2018/10/25