Spotlight works on both content and metadata, but it doesn’t rely on the FS to do live indexing.
It happens above, at vfs layer, which trigger on nodes activity several Spotlights extentions to create/update index on the file metadata and its content.
The main difference is that it can works on any file systems and that it can update index even on full content that way. Otherwise, I agree, the performance will be similar anyway.
And file deletion is also slow, when you are working with 40k files or more. Maybe being a slow external drive and in VM affects so much, but seems like in linuxes in vms it goes somewhat faster.
Yeah that seems reasonable at least at face value… however that is also basically what Baloo is right, and it’s a second generation attempt by KDE to do this and there are numerous reports of it sucking almost as much as nepomunk did? I couldn’t find it now but there was a blog post about how it was supposed to be leagues faster after some optimisations they did in it’s design… yet there those posts are by users still having problems with it.
Haiku’s disk IO may be slower but it is mostly consistent at least…
Being able to configure the level of indexing might be nice, since that is a drawback of how Haiku does it now.
It is interesting to know how much this slowiness is caused by enabled debugging mode in the kernel and how much by not good enough programming.
Any way, I gues, there is much to do in Haiku to achive Linux perfomance.
Only more advanced architecture of the system targeted for desktop usage helps Haiku to look agile and fast. Actualy Haiku for now is slow: you can see that when she works with archyves and copying files.
I really hope that this situation will be better.
@damoklas, that is probably down to USB and or BFS, not the rest of Haiku at large. Also potentially the expander… For instance 7-zip is an order of magnitude faster than the built in Windows zip extractor could be a lot of the slowdown is there.
Interestingly Linux is using multihreaded IO everywhere now… with blk-mq so that may be an area of improvement also. Note that it’s really targeted more for systems with > 2 disks though it should help on extremely low latency disks also. Definitly worth a read: https://events.static.linuxfound.org/sites/events/files/slides/scsi.pdf
This isn’t as big of a deal until people start using CPUs more like ThreadRipper and IO devices like NVME.
I think it has something to do with the BFS. The OS is responsive while i delete files, but not on task that use the disk (bottleneck case).
I can get this to happen in internal laptop drives cases where i delete things like the unzipped source code for gtk3 (many many files) or something with a high file count. Filesize doesnt seem to matter, it’s more like just file count.
But i’m working in 32bits machine so it might just work much better in 64bits (i dont know).
Ah yes I have noticed that, I’d say that’d be the IO scheduler not being fair enough… Linux has had similar problems in the past and even today. Less noticeable with faster disks though.
The solution would likely actually make your file transfer slower, but increase system responsiveness… It’s doubtful 64bits or debugging vs release would make a difference as it would require code improvements to make the IO more fair.
The problem here is we just do more than other OS when modifying files, in part because of updating the attribute index (and even if you move it out of the FS, you still will have to update it), and in part because of node monitoring (everytime we touch a file, we must ask ourselves “is someone monitoring this? should we send a notification?”).
You can avoid at least the first part by putting your sourcecode on a separate volume formatted with “disable queries support” (option available in DriveSetup).
I asumed that it was going to be a reason (and for low file count it rocks, i like the attributes features on files despite not having used them yet). Maybe not when moving (as that would incur in rename operation too), but when rm-ing a lot of items,could the monitoring / indexing be tuned to skip some of the work?
Unfortunately, i already use a separate volume (virtual disk) but it’s already formated with queries enabled flag (doh!)
Honestly, I think it is largely due to the drawing back-end. It is a mixture of being multithread and having simple drawing primitives. Even under linux, the app_server would work in multithread. And I think that’s enough for responsivity.
About the Be Inc. viral marketing, I think there is only one feature which is unique in the BeOS world, i.e. the B_DO_NOT_RESCHEDULE thing. This allows in theory to run something, give control to the kernel, then have the other user space module to do the work without rescheduling in the middle. This functionality, has been implemented in android using the binder. I think that’s the only real unique feature of the kernel in this sense.
Though the evolution of Qt app development on the Haiku platform has improved, I am still not a fan of it as the apps do not feel at home in Haiku (much like Java Swing apps IMHO). We have to find a way to make native application development easier and rewarding. If it was me, I’d place both Paladin and Pe into maintenance mode and keeping them working until a better app development tool solution could be built. There’s obviously been many attempts on both BeOS and Haiku to make app development easier, but has been a hit-n-miss affair. I got excited about the ALE Editor until I discovered that it’s generally broken. There are other tools like it that are also broken. It would also be great to have a native Haiku IDE that supported both C++ and BASIC (hence yab) related development with all the useful bells and whistles to get app development done. It doesn’t have to be Visual Studio, but at least something that makes building apps fun and enjoyable (not that VS actually succeeds in this regard).
We’re not going to get anywhere by putting apps in maintenance mode and attempting to replace them. Man-years of work went into both Paladin and Pe, and restarting from scratch is just going to cost Man-years again, to reach, at best, a different set of missing features.
KapiX did evaluate Pe carefully and went for a rewrite in Koder, with good success so far. And Adam is currently working on improving Paladin at an amazing pace. I prefer going this way instead of going with yet another rewrite.
If you have any grist with either app (or ALE or anything), just make feature requests and bugreports. Only then we can see if a rewrite is needed (I think, only very rarely this is the case).
ALE is broken and IMO I’m not so sure it should be fixed. The way the ALE model works is mostly incompatible with right-to-left layouts (which we don’t support but intend to eventually), among other things. We do need a WYSIWYG designer for our native layout API, but ALE should probably be phased out.
Yes, Pe’s code is an utter nightmare. Speaking of which, Koder has advanced to the point we should probably replace Pe with it in default installs…
I agree. 
There’s lots of good stuff planned for Paladin, much of which should be complete by the New Year. All the existing bugs/annoyances should be fixed by 5th November, with a release around then. For details on what is planned, and to request more features/fixes for paladin, visit this: Milestones - HaikuArchives/Paladin · GitHub
The ultimate aim I have with Paladin is to make brand new Haiku developers’ lives much easier. This will be achieved through support for multiple languages, extensive samples and tutorials, and generally handling all the ‘plumbing’ that you would otherwise have to do on the command line (Makefile creation, library linking, and so on).
For particular language and development UI support, please do add an enhancement request to GitHub. Otherwise it leaves me just guessing, and I’m likely to concentrate more on C++ development improvements, for lack of people asking for other features.
I’m happy for Paladin to be the trialling place for other wacky ideas, including new Haiku API suggestions. I already have one idea around multiple window/app layouts as an extension to the Layout Kit that I want to try out soon at BeGeistert. This is why we have feature branches, after all!
The V\OS link is now a 404. Anyone know how that turned out?
seem he (barret) delete the repo… or abandon his project
How’s Koder looking three years on? Pe is still in default installs, so maybe it’s time to switch it out?
Koder have some really annoying bugs, like the scrollbar not proportional to the document lenght, therefore you cant scroll to the en of the document using it. It happens randomly, maybe my font / fontsize the culprit.
Also find and replace sometimes doesnt finds and replaces every occurances.
And sadly it is really slow with big files.
I am not telling Pe is better, i just say it have bugs too.
KapiX, the developer of Koder, has asked that we do not include it by default in Haiku until it’s ready. It has some bugs and some missing features for now.
Pe is much better for me because it have code navigation, header list, more powerful search, file compare, patch file navigation, command execution, compiler error list and much more features that I often use.