bugGNU TeXmacs - Bugs: bug #36714, CPU hogging.

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #36714: CPU hogging.

Submitter:  Alan Grimes <alonzotg>
Submitted:  Sat 23 Jun 2012 11:23:34 PM UTC
   
 
Category:  Editor Priority:  7 - High
Item Group:  Error Status:  Need Info
Privacy:  Public Assigned to:  vdhoeven
Originator Name:  Open/Closed:  Closed
Release:  None Release:  1.0.7.15
Fixed Release:  None Fixed Release: 
Keywords: 

Jump to the original submission

Thu 23 Mar 2017 10:02:52 PM UTC, comment #9: 

There was no news about this bug for 4.5 years, even after Joris specifically asked => Looks stalled and unlikely to evolve. Closing.

Philippe Joyez <pjoyez>
Group Member
Wed 27 Nov 2013 05:14:20 PM UTC, comment #8: 

Is this bug still present?  Also, is the bug present in the X11 version?  It might be related to the way events are being handled by Qt (e.g. permanently pulling events instead of using a clean callback or pulling, say, every second or so).

Joris van der Hoeven <vdhoeven>
Group administrator
Fri 14 Sep 2012 12:41:56 AM UTC, comment #7: 

Okay, here is the callgraph of pthread_getspecific. Brown is libguile (possibly indicating a widget setup issue). aqua-green is texmacs proper, green is libQtCore.so

Hmm, that looks like the culprit, that super-long chain ending in tmscm_object_rep...


Alan Grimes <alonzotg>
Thu 13 Sep 2012 06:25:02 PM UTC, comment #6: 

TeXmacs does not use the STL for historical and practical reasons.  (i doubt this is the reason for the CPU hogging on your machine). fast_new and fast_delete are a custom memory allocator since for small datastuctures (many lists and trees) texmacs does a custom memory management which is more efficient than malloc. ~tree() is due to the fact that the tree destructor is virtual (for a series of complex reasons). this desing decision has been evaluated and for the moment there are no plans of moving to a non-virtual class organization for trees. please note that if you do not type something then TeXmacs should take a very small amount of CPU time, all the heavy computations with trees happens at the moment of the typesetting (or loading of files). The p-thead calls are more suspicious, but from your description I cannot deduce what they are due to. Could you have some call tree to send us so that I undestand why texmacs is doing that?
Guile is inefficient but again in normal situation all the inefficiencies due to guile are a bit cured by judicious caching and the rest usually is simply unavoidable given the desing goals of the program.

Can you manage to compile 32 bits to see if the bug persists?

Do you have some ideas about the way you trigger it?

thanks for the report.

Massimiliano Gubinelli <mgubi>
Group administrator
Thu 13 Sep 2012 04:29:26 PM UTC, comment #5: 

Yes, the problem still persists in the version shipped with my distribution, it is the same version as in the bug discription. Compiling this manually will require a great deal of work, which I'm not quite in the mood to do right now.

I just ran the profiler as suggested, There is a bunch of suspicious stuff going on... What's with all these fast_new fast_delete calls? Furthermore, there were 11 million calls to ~tree()... I thought tree was a STL class? Most of the time was actually in libguile.so (17.4.0) "deval'2" and "scm_dapply'2" consumed most of the time and scm_ihasq was called over 9 million times...

So my preliminary diagnosis is that you're using buggy custom functions for stuff you should be just leaning on the standard utilities for, furthermore, you are building up trees and stuff to solve intermediate problems where you would be much better served by much fewer, more persistent, instances of these such that the build up and tear-down time would be nulled out.

I'm still not sure why it's hogging CPU, It seems to be making p-thread calls. (about 15% of the CPU usage is system time).  JFC!!! Pthread_getspecific was called 35 MILLION TIMES!!!!!

Alan Grimes <alonzotg>
Wed 12 Sep 2012 11:47:35 AM UTC, comment #4: 

Did you again experienced this bug ?

Francois Poulain <fpoulain>
Group Member
Sat 30 Jun 2012 10:33:19 PM UTC, comment #3: 

I think it is a bug related to autosave, which has been fixed in the trunk. Could you please try to compile svn version and test to reproduce the bug ?

Francois Poulain <fpoulain>
Group Member
Sun 24 Jun 2012 01:18:48 PM UTC, comment #2: 

The build is gentoo x64. I used the stock e-build, no monkeying.

[ebuild   R    ] app-office/texmacs-1.0.7.15-r1  USE="imlib jpeg netpbm qt4 spell svg" 0 kB

Alan Grimes <alonzotg>
Sun 24 Jun 2012 12:29:16 PM UTC, comment #1: 

This does not happen to me, running Linux. Already in April it did not seem to hit everybody.
What OS are you using? Did you compile yourself?

Philippe Joyez <pjoyez>
Group Member
Sat 23 Jun 2012 11:23:34 PM UTC, original submission:  

The issue noted on the mailing list back in April persists. I was in the mood to try my hand at writing a paper, so I pulled up the article template and started writing. A few minutes later, my CPU usage was at 100%. To reproduce, simply fire it up, load a document wait two minutes. It pegs a single core at 100% A core on my machine is worth about 6 billion instructions per second, so we're talking colossal wastage here.

Running the program in a code profilier for several minutes should highlight the code that's actually running and, by extension the code that causes it to run excessively.

Alan Grimes <alonzotg>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by vdhoeven (Posted a comment)
  • -email is unavailable- added by mgubi (Posted a comment)
  • -email is unavailable- added by pjoyez (Posted a comment)
  • -email is unavailable- added by alonzotg (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-03-23 pjoyez Open/ClosedOpen Closed
    2013-11-27 vdhoeven Priority5 - Normal 7 - High
    2013-11-27 vdhoeven Assigned toNone vdhoeven
    2012-09-14 alonzotg Attached File- Added pthread_getspecific_texmacs.png, #26552
    2012-06-24 pjoyez StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code