This is the old SliTaz forum - Please use the main

Performance issues.
  • XavierJXavierJ October 2010
    I every one.

    I'm calling for you help again because I can't figure out this problem.

    I have a base Slitaz distro on which I run a particular program. It is usualy runned on a ubuntu server distro, and It is significantly slower on Slitaz than on ubuntu.

    Is there something missing on Slitaz base that could explain that ? (I really don't know the cause of the problem and how to analyse it, so I'm sorry but I can't formulate a more precise question.)

    The only two leads I could think about are the lack of swap on my Slitaz system -but there is no reason the program would require swaping-, and something to do with the acpi.

    Any clue would be appreciated ;-)
  • ChristopheChristophe October 2010
    ubuntu and slitaz have a different base.
    I have an awk program that needs 7 seconds on ubuntu and 2 or 3 minutes on slitaz, to do the same thing.
    slitaz will use less memory hence swapping will not be an issue (if it was not with ubuntu)
  • XavierJXavierJ October 2010
    You say that ubuntu and slitaz have a different base, but the kernel and the c libs are the sames.
    What part of the system could explain the difference between the two ?
  • Trixar_zaTrixar_za October 2010
    Ubuntu is based on Debian, which was built up off the linux kernel and GNU tools. You can then say something based off Ubuntu, like Mint, is also debian based.

    SliTaz however was built from the ground up with the Linux Kernel and the lightweight and multi-functional busybox. That's the difference. SliTaz isn't based on any prior distro where Ubuntu is based and built on Debian.
  • XavierJXavierJ November 2010
    It turned out that -among other things- my kernel wasn't optimized. I changed a bit my kernel config (mostly I deselected "optimize for size"), now it's a bit better.
  • XavierJXavierJ November 2010
    I still wonder why slitaz is slower than ubuntu.

    I just realized that tazpkgs may be optimized for size and not for speed. That would be natural. Is it the case ?
  • bellardbellard November 2010
    Are you running an X86_64 cpu ?
    SliTaz is built for i486.
  • XavierJXavierJ November 2010
    I'm running a x86 cpu (intel atom N270). My storage device is a flash card.
  • ChristopheChristophe November 2010
    Your assuption might be correct (optimisation for size and not for speed). Are there any "global" instructions for packages optimisation ?

    This being said, I noticed the system is slowing down after having been up for a while, and I have read reviews of others saying the same. I understand it may not be the priority but some day, someone "in the know" might want to have a look on that.
  • GawronGawron November 2010
    On my ThinkPad 450MHz SliTaz 3.0 boots in 13 sec, Ubuntu without gui needs 2min 30sec. The only missing part is polish locale pack, but I have copied polish locales from debian to /usr/share/locale and /usr/share/i18n/locales and partly all works. I'm happy SliTaz user. Thank you developers. Please don't give up your good work.
  • XavierJXavierJ November 2010
    Don't get me wrong, I'm not complaining, I'm just trying to understand and to fix it if I can.
    My slitaz also boot much faster than ubuntu, the problem comes after: program are running slower than on ubuntu.

    The weird thing is that nor the cpu nor the ram are fully used.
    I tried changing the kernel or the libc but without any improvement so far.
  • Trixar_zaTrixar_za November 2010
    Can you elaborate on which programs are running slower?

    Are you using OpenGL? Programs that cache (like Firefox)?

    OpenGL programs are noticeably slower than they'd be on Ubuntu because it defaults to software rendering instead of hardware. This is most notable with programs that's heavily dependant on mesa. I noticed that my Firefox gets slower if I don't flush the cookies and cache every now and again. Tracking cookies are the worst, even though I'm using adblock plus to block the majority of them. But on a whole, SDL programs for example tend to run slight faster than they do on Ubuntu - even packages converted over from it's packages.

    Another issue might be busybox. The commands it replaces aren't very optimised, especially when you use multiple functions at the same time. This would create a noticeable speed difference with complicated functions (because it's using busybox multiple times at the same time), while simple functions should be about the same speed, if not faster.

    Generally it's one or two programs that get slower and not the OS itself for me. I will agree that that it's not exactly compiled for speed, but rather for size. This could probably be optimised along with doing mesa properly, so that OpenGL runs through the hardware rather than software. That would be a huge speed boost for SliTaz.
  • XavierJXavierJ November 2010
    I'm not using any GUI. The program I run is Urbi: my Slitaz is used to power a robot an Urbi control it.

    I have benchmarked Ubuntu and Slitaz on the same hardware. Here are the results: ubuntu: Slitaz:
    I'm not an expert in benchmarking but Slitaz scores are definitely under Ubuntu scores.

    The benchmark also tells that slitaz is using SYSENTER/SYSEXIT and ubuntu is not.
  • Trixar_zaTrixar_za November 2010
    Ubuntu uses bash shell by default while slitaz uses busybox's ash. Like you can see calling busybox multiple times really does dent it's performance.

    You could try replacing ash with bash. Installing coreutils and all the other coreutils-* packages should help free up busybox from (some of) the multiple calls, while replacing busybox's commands with the real ones.
  • XavierJXavierJ November 2010
    Replacing busybox by bash and installing coreutils may help for all shell commands calls, but it won't improve system calls.

    I'm trying it anyway, I will let you know the results.
  • XavierJXavierJ November 2010
    It's not better, maybe even worst...

    I'm trying to build the glibc for my kernel but so far I'm only getting compile errors...
  • XavierJXavierJ November 2010
    Do you think that compiling for i486 (as the tazpkg are) is much slower than compiling for i686 ?
    Providing that the hardware is i686 compliant of course.
  • Trixar_zaTrixar_za November 2010
    Either should be fine. Even i386 packages should be alright on most modern systems. In fact I've seen packages compiled with an i686 system, while others (the majority) are compiled for i486. From what I read about them long ago, the difference is actually pretty minor. For example many Slackware systems use i486 packages, Fedora based distros tend to use i686 and Debian tends to use i386. They're all essentially the same package, but with certain optimisations for that certain distro's core.

    As for the test using bash and coreutils - that created fair comparison and if the results are worse than using ash and busybox, then it's clear something or several something in the kernel and code isn't being optimised for the best of the OS. Might be worth one of the devs attention to investigate this and make the appropriate changes.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social